From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL return value in after triggers |
Date: | 2012-01-23 21:48:32 |
Message-ID: | CAFj8pRARVKiLMztaCZWcZ7Jn0qGTKG5G4s97dHGLz=ROHsbcTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Peter
I checked code, and I don't think so this is good.
A design of optional NULL is going to inconsistent syntax.
RETURN (OLD, NEW, NULL, /* nothing */) is not consistent
But my main argument is not intuitive behave of BEFORE triggers after
this change.
When somebody write BEFORE trigger function like:
BEGIN
RAISE NOTICE '%', NEW.x;
RETURN;
END;
then don't expect so all rows will be lost.
Preferred default return value for BEFORE INSERT UPDATE trigger should
be NEW, and for DELETE trigger should be OLD - not NULL.
And because we cannot to distinct between BEFORE and AFTER trigger in
parser, I propose don't change current behave. Current behave is not
too friendly - but is consistent with simple rules.
Regards
Pavel
2012/1/2 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On mån, 2011-02-28 at 19:07 +0200, Peter Eisentraut wrote:
>> PL/pgSQL trigger functions currently require a value to be returned,
>> even though that value is not used for anything in case of a trigger
>> fired AFTER. I was wondering if we could relax that. It would make
>> things a bit more robust and produce clearer PL/pgSQL code. The
>> specific case I'm concerned about is that a trigger function could
>> accidentally be run in a BEFORE trigger even though it was not meant for
>> that. It is common practice that trigger functions for AFTER triggers
>> return NULL, which would have unpleasant effects if used in a BEFORE
>> trigger.
>>
>> I think it is very uncommon to have the same function usable for BEFORE
>> and AFTER triggers, so it would be valuable to have coding support
>> specifically for AFTER triggers. We could just allow RETURN without
>> argument, or perhaps no RETURN at all.
>
> Here is a patch for that.
>
> One thing that I'm concerned about with this is that it treats a plain
> RETURN in a BEFORE trigger as RETURN NULL, whereas arguably it should be
> an error. I haven't found a good way to handle that yet, but I'll keep
> looking.
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-01-23 21:54:30 | Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility |
Previous Message | Merlin Moncure | 2012-01-23 21:45:13 | Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements |