Re: BUG #5066: plperl issues with perl_destruct() and END blocks
От | David Fetter |
---|---|
Тема | Re: BUG #5066: plperl issues with perl_destruct() and END blocks |
Дата | |
Msg-id | 20090921184519.GM31599@fetter.org обсуждение исходный текст |
Ответ на | Re: BUG #5066: plperl issues with perl_destruct() and END blocks (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-bugs |
On Mon, Sep 21, 2009 at 02:28:11PM -0400, Robert Haas wrote: > On Mon, Sep 21, 2009 at 2:17 PM, David Fetter <david@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. OK, we've considered it and decided it's people's own foot-gun :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-bugs по дате отправления: