pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedPatch to fix documentation about AFTER triggers
3+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2017-05-16 8e709a612f doc: Remove unnecessary RETURN statements from example.
* Patch to fix documentation about AFTER triggers
@ 2017-05-12 21:15 Paul Jungwirth <pj@illuminatedcomputing.com>
2017-05-15 11:00 ` Re: Patch to fix documentation about AFTER triggers Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
0 siblings, 1 reply; 3+ messages in thread
From: Paul Jungwirth @ 2017-05-12 21:15 UTC (permalink / raw)
To: pgsql-hackers
Here is a patch to amend the docs here:
https://www.postgresql.org/docs/devel/static/plpgsql-trigger.html
In the example for an AFTER trigger, you see this code:
--
-- Create a row in emp_audit to reflect the operation performed on emp,
-- make use of the special variable TG_OP to work out the operation.
--
IF (TG_OP = 'DELETE') THEN
INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*;
RETURN OLD;
ELSIF (TG_OP = 'UPDATE') THEN
INSERT INTO emp_audit SELECT 'U', now(), user, NEW.*;
RETURN NEW;
ELSIF (TG_OP = 'INSERT') THEN
INSERT INTO emp_audit SELECT 'I', now(), user, NEW.*;
RETURN NEW;
END IF;
RETURN NULL; -- result is ignored since this is an AFTER trigger
What are all those RETURNs doing in there? The comment on the final
RETURN is correct, so returning NEW or OLD above seems confusing, and
likely a copy/paste error.
This patch just removes those three lines from the example code.
Thanks!
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
plpgsql_trigger_docs_v1.patch (text/x-patch, 765B) download
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index a6088e9..dc29e7c 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -3999,13 +3999,10 @@ CREATE OR REPLACE FUNCTION process_emp_audit() RETURNS TRIGGER AS $emp_audit$
--
IF (TG_OP = 'DELETE') THEN
INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*;
- RETURN OLD;
ELSIF (TG_OP = 'UPDATE') THEN
INSERT INTO emp_audit SELECT 'U', now(), user, NEW.*;
- RETURN NEW;
ELSIF (TG_OP = 'INSERT') THEN
INSERT INTO emp_audit SELECT 'I', now(), user, NEW.*;
- RETURN NEW;
END IF;
RETURN NULL; -- result is ignored since this is an AFTER trigger
END;
* Re: Patch to fix documentation about AFTER triggers
2017-05-12 21:15 Patch to fix documentation about AFTER triggers Paul Jungwirth <pj@illuminatedcomputing.com>
@ 2017-05-15 11:00 ` Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
2017-05-16 15:54 ` Re: Patch to fix documentation about AFTER triggers Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Ashutosh Bapat @ 2017-05-15 11:00 UTC (permalink / raw)
To: Paul Jungwirth <pj@illuminatedcomputing.com>; +Cc: pgsql-hackers
On Sat, May 13, 2017 at 2:45 AM, Paul Jungwirth
<pj@illuminatedcomputing.com> wrote:
> Here is a patch to amend the docs here:
>
> https://www.postgresql.org/docs/devel/static/plpgsql-trigger.html
>
> In the example for an AFTER trigger, you see this code:
>
> --
> -- Create a row in emp_audit to reflect the operation performed on emp,
> -- make use of the special variable TG_OP to work out the operation.
> --
> IF (TG_OP = 'DELETE') THEN
> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*;
> RETURN OLD;
> ELSIF (TG_OP = 'UPDATE') THEN
> INSERT INTO emp_audit SELECT 'U', now(), user, NEW.*;
> RETURN NEW;
> ELSIF (TG_OP = 'INSERT') THEN
> INSERT INTO emp_audit SELECT 'I', now(), user, NEW.*;
> RETURN NEW;
> END IF;
> RETURN NULL; -- result is ignored since this is an AFTER trigger
>
> What are all those RETURNs doing in there? The comment on the final RETURN
> is correct, so returning NEW or OLD above seems confusing, and likely a
> copy/paste error.
>
> This patch just removes those three lines from the example code.
https://www.postgresql.org/docs/devel/static/trigger-definition.html says
"The return value is ignored for row-level triggers fired after an
operation, and so they can return NULL.". There's nothing wrong with
the example, returning OLD or NEW, but as you have pointed out it's
confusing. So, +1 for this change.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Patch to fix documentation about AFTER triggers
2017-05-12 21:15 Patch to fix documentation about AFTER triggers Paul Jungwirth <pj@illuminatedcomputing.com>
2017-05-15 11:00 ` Re: Patch to fix documentation about AFTER triggers Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
@ 2017-05-16 15:54 ` Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Robert Haas @ 2017-05-16 15:54 UTC (permalink / raw)
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>; +Cc: Paul Jungwirth <pj@illuminatedcomputing.com>; pgsql-hackers
On Mon, May 15, 2017 at 7:00 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> On Sat, May 13, 2017 at 2:45 AM, Paul Jungwirth
> <pj@illuminatedcomputing.com> wrote:
>> Here is a patch to amend the docs here:
>>
>> https://www.postgresql.org/docs/devel/static/plpgsql-trigger.html
>>
>> In the example for an AFTER trigger, you see this code:
>>
>> --
>> -- Create a row in emp_audit to reflect the operation performed on emp,
>> -- make use of the special variable TG_OP to work out the operation.
>> --
>> IF (TG_OP = 'DELETE') THEN
>> INSERT INTO emp_audit SELECT 'D', now(), user, OLD.*;
>> RETURN OLD;
>> ELSIF (TG_OP = 'UPDATE') THEN
>> INSERT INTO emp_audit SELECT 'U', now(), user, NEW.*;
>> RETURN NEW;
>> ELSIF (TG_OP = 'INSERT') THEN
>> INSERT INTO emp_audit SELECT 'I', now(), user, NEW.*;
>> RETURN NEW;
>> END IF;
>> RETURN NULL; -- result is ignored since this is an AFTER trigger
>>
>> What are all those RETURNs doing in there? The comment on the final RETURN
>> is correct, so returning NEW or OLD above seems confusing, and likely a
>> copy/paste error.
>>
>> This patch just removes those three lines from the example code.
>
> https://www.postgresql.org/docs/devel/static/trigger-definition.html says
> "The return value is ignored for row-level triggers fired after an
> operation, and so they can return NULL.". There's nothing wrong with
> the example, returning OLD or NEW, but as you have pointed out it's
> confusing. So, +1 for this change.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2017-05-16 15:54 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-05-12 21:15 Patch to fix documentation about AFTER triggers Paul Jungwirth <pj@illuminatedcomputing.com>
2017-05-15 11:00 ` Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
2017-05-16 15:54 ` Robert Haas <robertmhaas@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox