On 3/14/08, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 2:18 PM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 3/13/08, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > > An application which uses tsearch2 ('SELECT set_curdict() /
> > set_curcfg()' being
> > > called upon session start). That is fine and that works.
> > >
> > > Now, using statement pooling solution like pgbouncer is great benefit
> for this
> > > specific application. There is one little problem however -- one can
> never be
> > > sure when session is started. As a countermeasure there is a need to
> call
> > > set_curdict() in every transaction (which is very fast), but one needs
> > > to remember
> > > to call that set_curdict() every time.
> > >
> > > ON CONNECT trigger would solve that neatly!
> >
> > Hm. It seems to make more sense to implement connect-time
> > hook directly in pgbouncer.
>
> Indeed that would solve the issue. But then again it could be argued that
> PL/pgSQL could be implemented outside the backend as well. ;-)
Well, as the transaction-pooling breaks application expectations
and makes impossible for them to do initial setup, the connect
hook could give a way to compensate for that.
> I see it as an addition which does have its applications.
To put it to core Postgres, it needs to be conceptually sane
first, without needing ugly workarounds to avoid it bringing
whole db down.
I can see ATM only few ways:
- Applies only to non-superusers.
- Error from CONNECT trigger does not affect superuser.
- Applies to database + role. Role could be also group of users.
So you always have way do fix things, without hexediting in data dir...
--
marko
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
