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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Дата
Msg-id 603c8f070909211232j67879e3dk1ade46d76f90927a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5066: plperl issues with perl_destruct() and END blocks  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-bugs
On Mon, Sep 21, 2009 at 3:08 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> David Fetter escribi=F3:
>> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
>
>> > The fine manual saith
>> >
>> > =A0 =A0 You may have multiple "END" blocks within a file--they will
>> > =A0 =A0 execute in reverse order of definition; that is: last in, first
>> > =A0 =A0 out (LIFO).
>> >
>> > But then, why would we care? =A0We just call the destructor and Perl
>> > ensures that the blocks are called in the right order.
>>
>> This is not quite what I meant. =A0Let's say we have two or more differe=
nt
>> PL/Perl functions executed over the course of a backend. =A0Which one's
>> END block gets executed last?
>
> I think the manual is quite clear on this point. =A0It talks about "files"
> which we don't have, but other than that it doesn't seem like there
> shouldn't be any problem.
>
> Now that I think about it, this only affects loaded modules, not the
> plperl functions themselves, right? =A0I mean, you can't define an END
> block inside a function.

You might think that, but it turns out the world of Perl is crazier
than the ordinary mind can fathom.

$ perl -e 'sub foo { END { print "hi\n" } }'
hi

...Robert

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Christine Penner
Дата:
Сообщение: Re: Problem installing Postgres 8.4.1
Следующее
От: Matt Taylor
Дата:
Сообщение: Re: BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL