Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alex Hunsaker <badalex@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Jan Urbański <wulczer@wulczer.org>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-01T22:59:48Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove unnecessary use of trigger flag to hash plperl functions

Alex Hunsaker <badalex@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