Re: why does plperl cache functions using just a bool for is_trigger - Mailing list pgsql-hackers

From Tom Lane
Subject Re: why does plperl cache functions using just a bool for is_trigger
Date
Msg-id 7361.1288652388@sss.pgh.pa.us
Whole thread Raw
In response to Re: why does plperl cache functions using just a bool for is_trigger  (Alex Hunsaker <badalex@gmail.com>)
Responses Re: why does plperl cache functions using just a bool for is_trigger
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SR fails to send existing WAL file after off-line copy
Next
From: Merlin Moncure
Date:
Subject: Re: revision of todo: NULL for ROW variables