Re: [HACKERS] Delaying insertion of default values - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] Delaying insertion of default values
Date
Msg-id m112DSn-0003ktC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] Delaying insertion of default values  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
Vadim wrote:

> Jan Wieck wrote:
> >
> >     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.

    Sounds reasonable.

>
> 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 ...).

    In my understanding an SLT couldn't have worked for something
    like

        UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;

    Isn't this all still an AFTER trigger on ROW level that could
    be executed deferred?

    I like the aproach to give constraints the power of PL.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Delaying insertion of default values
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] acl problem in NetBSD/m68k