On 25/10/10 03:59, Andrew Dunstan wrote: > > > On 10/24/2010 09:34 PM, Tom Lane wrote: >> >>> For both trigger and non-trigger functions, we compile this ahead of the >>> user-set function code: >>> our $_TD; local $_TD=shift; >>> Non-trigger functions get passed "undef" to correspond to this invisible >>> argument, while trigger functions get passed the hashref that the >>> trigger calling code has set up. >> Seems like we don't need it then. You going to get rid of it? > > Ok, will do.
Seems that this circumverts some output conversion error checking, since adding the attached to the regression suite results in a segfault during the plperl installcheck. Reverting 2d01ec0708d571eef926f3f5795aa73759df5d9a fixes it. Noticed while fooling around with plpython and hitting a similar error (since plpython does have a regression test for trigger functions being called directly). Cheers, Jan
*** a/src/pl/plperl/expected/plperl_trigger.out --- b/src/pl/plperl/expected/plperl_trigger.out *************** *** 266,268 **** SELECT * FROM trigger_test; --- 266,274 ---- 4 | immortal (1 row) + CREATE OR REPLACE FUNCTION direct_trigger() RETURNS trigger AS $$ + return; + $$ LANGUAGE plperl; + SELECT direct_trigger(); + ERROR: trigger functions can only be called as triggers + CONTEXT: compilation of PL/Perl function "direct_trigger" *** a/src/pl/plperl/sql/plperl_trigger.sql --- b/src/pl/plperl/sql/plperl_trigger.sql *************** *** 130,132 **** DELETE FROM trigger_test; --- 130,138 ---- SELECT * FROM trigger_test; + + CREATE OR REPLACE FUNCTION direct_trigger() RETURNS trigger AS $$ + return; + $$ LANGUAGE plperl; + + SELECT direct_trigger();
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
