Re: [HACKERS] Delaying insertion of default values

Jan Wieck wrote:
> 
> > BTW, what's your plan for RI constraints, Jan?
> > Did you see my letter about statement level triggers?
> > If I'll get WAL implemented then it could be used for RI.
> > In any case I believe that statement level triggers
> > are very nice thing and they are better for RI than
> > rules.
> 
>     What's WAL?

Write Ahead Log. We could backward scan WAL to get tid of
changed primary/unique/foreign table rows and check constraints.
More of that, we could write to WAL RI infos only for rows with
updated _keys_ to avoid check for cases when there was no key
update.

...
>     Currently  rules  cannot do this job too. I planned to change
>     the handling of snapshot as  discussed  and  to  implement  a
>     deferred  querytree  list  ran  at  appropriate  times  (like
>     COMMIT). Plus a new RAISE command that's internally most of a
>     SELECT  but throwing an elog if it finds some rows. Such a CI
>     rule would then look like:
> 
>         CREATE RULE reftab_check_refkey AS ON UPDATE TO reftab DO
>             RAISE 'foreign key % not present', new.refkey
>             WHERE NOT EXISTS
>             (SELECT keyval FROM keytab WHERE keyval = new.refkey);
> 
>     This rule will get expanded by the rewriter to do a scan with
>     the  snapshot when the UPDATE ran against reftab and with the
>     qual expanded to match the updated old tuples only,  but  the
>     subselect  will  have  the snapshot at commit time which will
>     find the newly inserted keytab row. I don't see how statement
>     level triggers can do it.

As far as I understand what is statement level trigger (SLT),
one is able to use NEW/OLD in queries of SLT just like as
NEW/OLD are used in rules. I would say that SLT-s are
rules powered by PL, and nothing more. You would just rewrite
each query of SLT with NEW/OLD in normal fashion. Using power
of PL _ANY_ constraints (not just simple RI ones) could be
implemented. 

Comments?

Vadim