Skip site navigation (1) Skip section navigation (2)

Re: BUG #5066: plperl issues with perl_destruct() and END blocks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Date: 2009-09-22 14:13:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> If the changes are simple, as Tim seems to believe, exactly what do we
> lose by doing this?

It's not simple.  There are any number of issues that Tim has not
addressed.  The most obvious: *his* use case might not require database
access in an END block, but that doesn't mean the next complainant won't
want it.

Another point that comes to mind is shared_preload_libraries: if plperl
is loaded once in the postmaster, it seems entirely likely that the same
END block would be executed in multiple backends after having been
loaded only once.  Again, while that might be okay for his particular
use-case, it seems horribly dangerous for anything else.

(The shared_preload_libraries case also destroys the most obvious
implementation path, ie having plperl add an on_proc_exit callback
at _PG_init time...)

But my basic objection is that a PL is a device for executing code in
functions.  It has no business being used to cause "action at a
distance" outside of those functions.  If we go down this path we are
going to regret it.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Robert HaasDate: 2009-09-22 15:09:02
Subject: Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Previous:From: nanda gopalDate: 2009-09-22 14:10:17
Subject: Requesting the Revision History

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group