On Mon, Nov 1, 2010 at 09:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think the crash is dependent on the fact that the function is created
> and called in the same session. That means the validator gets called on
> it first, and the validator not unreasonably assumes istrigger = true,
> and then it calls compile_plperl_function which sets up a cache entry
> on that basis. So then when the "regular" call comes along, it tries
> to reuse the cache entry in the other style. Kaboom.
The other Kaboom happens if the trigger gets called as a trigger first
and then directly.
>>> There is a check so that trigger functions can not be called as plain
>>> functions... I think just moving that up...
> No, that is just moving a test that only needs to be done once into a
> place where it has to be done every time. You might as well argue that
> we shouldn't cache any of the setup but just redo it all every time.
Huh? I might try and argue that if the new test was more complex than
2 compares :P. In-fact the way it stands now we uselessly grab the
functions pg_proc entry in the common case. Would you object to
trying to clean that up across all pls? Im thinking add an is_trigger
or context to each proc_desc, then check that in the corresponding
handlers. While im at it get rid of at least one SysCache lookup.
Thoughts? We can still keep the is_trigger bool in the hash key, as
you said below it is a good safety feature. I just wish the logic was
spelled out a bit more. Maybe im alone here.
> It's also the same way
> that the other three PLs do things, and I see no good excuse for plperl
> to do things differently here.
Im all in favor of keeping things between the pls as close as possible.
Speaking of which, pltcl stores the trigger reloid instead of a flag
(it also uses tg_reloid in the internal proname). It seems a tad
excessive to have one function *per* trigger table. I looked through
the history to see if there was some reason, it goes all the way back
to the initial commit. I assume its this way because it copied
plpgsql, which needs it as the rowtype might be different per table.
pltcl should not have that issue. Find attached a patch to clean that
up and make it match the other pls (err um plperl). It passes its
regression tests and some additional limited testing. Thoughts?