From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL return value in after triggers |
Date: | 2012-01-02 04:37:46 |
Message-ID: | 1325479066.12911.6.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
plpgsql-trigger-return.patch | text/x-patch | 9.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-01-02 04:43:46 | Re: information schema/aclexplode doesn't know about default privileges |
Previous Message | Peter Eisentraut | 2012-01-02 04:32:33 | controlling the location of server-side SSL files |