On Mon, Sep 21, 2009 at 2:17 PM, David Fetter <da...@fetter.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs