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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why does plperl cache functions using just a bool for is_trigger
Date: 2010-11-01 22:59:48
Message-ID: 7361.1288652388@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex Hunsaker <badalex(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2010-11-01 23:07:56 Re: revision of todo: NULL for ROW variables
Previous Message Tom Lane 2010-11-01 22:47:30 Re: SR fails to send existing WAL file after off-line copy