Alex Hunsaker <bada...@gmail.com> writes: > 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?
Surely, removing the internal name's dependency on the istrigger flag is wrong. If you're going to maintain separate hash entries at the pltcl level, why would you want to risk collisions underneath that? regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers