From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feedback on writing extensible modules |
Date: | 2009-06-01 16:41:43 |
Message-ID: | 1243874503.6902.42.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-06-01 17:15:17 | Re: search_path improvements |
Previous Message | Tom Lane | 2009-06-01 16:32:20 | It's June 1; do you know where your release is? |