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
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 |