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

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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5066: plperl issues with perl_destruct() and END blocks
Date: 2009-09-21 19:08:02
Message-ID: 20090921190802.GQ29793@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-bugs
David Fetter escribió:
> On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:

> > 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?

I think the manual is quite clear on this point.  It 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?  I mean, you can't define an END
block inside a function.

> Do we need to warn people about this?

I don't see why not -- in the docs, of course.

> Generate a WARNING, even?

"Log spam" anyone?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-bugs by date

Next:From: Christine PennerDate: 2009-09-21 19:23:45
Subject: Re: Problem installing Postgres 8.4.1
Previous:From: Sachin SrivastavaDate: 2009-09-21 18:57:05
Subject: Re: Problem installing Postgres 8.4.1

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