Re: why does plperl cache functions using just a bool for is_trigger

On Wed, Nov 3, 2010 at 10:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> OK, applied.

Thanks!

> I notice that plpython is also using the trigger relation's OID, but I
> don't know that language well enough to tell whether it really needs to.

This thread was started by someone working a plpython a validator, I
figured the two areas overlap somewhat and did not want to step on any
toes. Anyhow the patch is tiny. So toes should remain intact. Find
it attached.

Given that plpython can only return None/OK", "MODIFY" or "SKIP" and
looking around the code for a bit, I don't see any reason it needs it.
I only tried plpython3, but it passed an installcheck and some
additional testing (two tables with the same column name and different
types using the same trigger).

[ Aside ]
I almost thought using tgreloid was required as PLy_modify_tuple has:

plpython.c:748
modvalues[i] =
InputFunctionCall(&proc->result.out.r.atts[atti].typfunc,
^^^^^
NULL,
proc->result.out.r.atts[atti].typioparam
^^^^^

But Ply_procedure_get has this bit which gets run every time the
function is called:
plpython.c: 1336
/*
* Input/output conversion for trigger tuples. Use the result
* TypeInfo variable to store the tuple conversion info. We do this
* over again on each call to cover the possibility that the
* relation's tupdesc changed since the trigger was last called.
* PLy_input_tuple_funcs and PLy_output_tuple_funcs are responsible
* for not doing repetitive work.
*/
....
PLy_input_tuple_funcs(&(proc->result), tdata->tg_relation->rd_att);
PLy_output_tuple_funcs(&(proc->result), tdata->tg_relation->rd_att);
....

I double checked the other pls just for my sanity. They get it right,
that is look it up instead of using anything cached in proc_desc.