Jan Wieck wrote:
>
> > But I agreed that the size of parsetrees may be big and for
> > COPY...FROM/INSERTs we should remember IDs of modified
> > tuples. Well. Please remember that I implement WAL right
> > now, already have 1000 lines of code and hope to run first
> > tests after writing additional ~200 lines -:)
> > We could read modified tuple IDs from WAL...
>
> Not only on COPY. One regular INSERT/UPDATE/DELETE statement
> can actually fire thousands of trigger calls right now. These ^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, because of we have not Statement Level Triggers (SLT).
Deferred SLT would require us to remember _one_ parsertree for each
statement, just like deferred rules.
> triggers normally use SPI to execute their own queries. If
> such a trigger now uses a query that in turn causes a
> deferred constraint, we might have to save thousands of
^^^^^^^^^^^^^^^^^^^^^
> deferred querytrees - impossible mission. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why should we save _thousands_ of querytrees in the case
of row level trigger (I assume you mean one querytree for
each modified tuple)?
As I described in prev letter - we have to remember just
LastCommandIdProccessedByConstraint to stop fetching
tuples from WAL.
BTW, this is what sql3-12aug93 says about triggers and RI:
22)If the <trigger event> specifies UPDATE, then let Ci be the i-th <column name> in the <trigger column list>.
/* i.e UPDATE OF C1,..Cj */ T shall not be the referencing table in any <referential constraint
definition>that specifies ON UPDATE CASCADE, ON UPDATE SET NULL, ON UPDATE SET DEFAULT, ON DELETE SET NULL, or ON
DELETESET DEFAULT and contains a <reference column list> that includes Ci.
Interesting?
Vadim