Jan Wieck wrote:
>
> >
> > 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.
>
> Sounds reasonable.
Unfortunately, additional WAL reads are not goot for overall
system performance, but it's way.
> > 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.
>
> Ah - in contrast to what I thought SLT's would be. I thought
> an SLT would only be called once per statement, not once per
> tuple (... FOR EACH STATEMENT EXECUTE PROCEDURE ...).
Yes, SLT is called once per statement, but queries in SLT are
able to see _all_ old/new tuples affected by statement, just
like rule action queries are able to do it.
For the case of checking existance of primary key trigger
over referencing table could execute
SELECT count(*) FROM new
WHERE NOT EXISTS
(SELECT keyval FROM keytab WHERE keyval = new.refkey);
and abort if count returned is > 0.
The query above will be just rewritten by rewrite system.
SLTes are rule actions + all these nice IF, FOR etc
PL statements -:)
Actually, query above must be modified to deal with
concurrent updates. Some other xaction can delete keyval
and query will not notice this. To see concurrent update/delete
query must be able to read dirty data and wait for other
xactions. It's not easy to do. I need in more time to
think about this issue.
Vadim
