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