Re: PL/pgSQL return value in after triggers - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: PL/pgSQL return value in after triggers
Date
Msg-id 1325479066.12911.6.camel@vanquo.pezone.net
Whole thread Raw
In response to PL/pgSQL return value in after triggers  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: PL/pgSQL return value in after triggers  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: PL/pgSQL return value in after triggers  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: PL/pgSQL return value in after triggers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.


Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: controlling the location of server-side SSL files
Next
From: Peter Eisentraut
Date:
Subject: Re: information schema/aclexplode doesn't know about default privileges