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

On Mon, Sep 21, 2009 at 2:17 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
>> David Fetter escribió:
>> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
>> > > David Fetter escribió:
>> > >
>> > > > Taken literally, that would mean, "the last action before the
>> > > > backend exits," but at least to me, that sounds troubling for
>> > > > the same reasons that "end of transaction" triggers do.  What
>> > > > happens when there are two different END blocks in a session?
>> > >
>> > > The manual is clear that both are executed.
>> >
>> > So it is, but does order matter, and if so, how would PostgreSQL
>> > know?
>>
>> The fine manual saith
>>
>>       You may have multiple "END" blocks within a file--they will
>>       execute in reverse order of definition; that is: last in, first
>>       out (LIFO).
>>
>> But then, why would we care?  We just call the destructor and Perl
>> ensures that the blocks are called in the right order.
>
> This is not quite what I meant.  Let's say we have two or more different
> PL/Perl functions executed over the course of a backend.  Which one's
> END block gets executed last?  Do we need to warn people about this?
> Generate a WARNING, even?

This is a feature of the Perl language. I don't think it's our job to
second-guess the language design, however good or bad it may be. As a
long-time Perl programmer, I would certainly say that if you are
counting on the execution ordering of your END blocks, you are
probably playing with fire and likely ought to rethink your
application design, because there are all kinds of ways this could
fail spectacularly as a result of apparently innocuous application
changes (like, say, alphabetizing the list of "use" declarations in
some package). But that's true not only with PL/perl but with just
plain old perl, and I don't see that it's substantially more dangerous
here than anywhere else.

...Robert