Re: Feedback on writing extensible modules - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Feedback on writing extensible modules
Date
Msg-id 1243874503.6902.42.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Feedback on writing extensible modules  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Mon, 2009-06-01 at 12:23 -0400, Alvaro Herrera wrote:
> Dimitri Fontaine wrote:
> 
> > Le 31 mai 09 à 18:21, Tom Lane a écrit :
> 
> >> You could maybe make this work by executing your own transaction
> >> to do it, but I really have to wonder if it's a good idea.  One
> >> point to think about is that elog(ERROR) still means elog(FATAL)
> >> at this point, so any brokenness in the queries you're trying to
> >> prepare will result in locking all users out of the database.
> >
> > Yeah that's a pretty good foot gun, yet another one. But  
> > preprepare.at_init is optional and defaults to off. If you broke it all, 
> > you can turn it off again and reload.
> 
> Maybe you could set a callback to be called during the first transaction
> in InitPostgres ... in full knowledge that if it fails, people will be
> locked out of the database.

Should be possible to define a custom variable that has an assign hook
that does nothing unless called with PGC_S_DATABASE or PGC_S_USER. That
should guarantee the code only runs after connection, rather than at
server startup. Not tried it yet.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Kevin Field
Date:
Subject: Re: plperl error format vs plpgsql error format vs pgTAP
Next
From: Josh Berkus
Date:
Subject: Re: search_path improvements