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

Interesting?

Vadim