Thread: BUG #2089: Documentation bug: Triggers in plpythonu

The following bug has been logged online:

Bug reference:      2089
Logged by:          Jozef Behran
Email address:      jozef.behran@krs.sk
PostgreSQL version: 8.1.0
Operating system:   Short answer: Mandrake 10.2. Long answer: Linux sarkan
2.6.11-6mdk #1 Tue Mar 22 16:04:32 CET 2005 i686 AMD Athlon(tm) Processor
unknown GNU/Linux
Description:        Documentation bug: Triggers in plpythonu
Details:

A trigger in plpythonu cannot use the `args' list to obtain the arguments
and does not return the row to be written into the database. Instead the
arguments are placed into a global dictionary called "TD". The row is in
TD["new"] as a dictionary keyed by the names of the fields (the values are
the values of the field). The trigger is supposed to return "SKIP" (or
None?) if it wants the operation to be skipped or modify the TD["new"] to
the actual content to be written into the database and then return "MODIFY".

Jozef Behran wrote:

> A trigger in plpythonu cannot use the `args' list to obtain the arguments
> and does not return the row to be written into the database. Instead the
> arguments are placed into a global dictionary called "TD". The row is in
> TD["new"] as a dictionary keyed by the names of the fields (the values are
> the values of the field). The trigger is supposed to return "SKIP" (or
> None?) if it wants the operation to be skipped or modify the TD["new"] to
> the actual content to be written into the database and then return "MODIFY".

I don't see how is this a bug.  It's perfectly documented in the
"Trigger functions" section, here:

http://www.postgresql.org/docs/8.1/static/plpython-trigger.html

If this is not what you meant, please explain.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> > A trigger in plpythonu cannot use the `args' list to obtain the
> > arguments and does not return the row to be written into the
> > database. Instead the arguments are placed into a global
> > dictionary called "TD". The row is in TD["new"] as a dictionary
> > keyed by the names of the fields (the values are the values of
> > the field). The trigger is supposed to return "SKIP" (or None?)
> > if it wants the operation to be skipped or modify the TD["new"]
> > to the actual content to be written into the database and then
> > return "MODIFY".
>
> I don't see how is this a bug.  It's perfectly documented in the
> "Trigger functions" section, here:

The problem was that I mistakenly read manual for the 8.0 version,
in which this is not documented (or at least no link is created from
the "trigger functions". There is no such bug in 8.1 manual and since
I use version 8.1.0 now, this does not matter.