Re: [HACKERS] Re: Referential Integrity In PostgreSQL

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 DELETE SET DEFAULT and contains a <reference column list>
that includes Ci.

Interesting?

Vadim