Re: pulling libpqtypes from queue - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: pulling libpqtypes from queue
Date
Msg-id b42b73150804151229x68673c95x790cc7d4c5d5fc5b@mail.gmail.com
Whole thread Raw
In response to Re: pulling libpqtypes from queue  (Andrew Chernow <ac@esilo.com>)
Responses Re: pulling libpqtypes from queue  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
On Tue, Apr 15, 2008 at 3:13 PM, Andrew Chernow <ac@esilo.com> wrote:
> Tom Lane wrote:
> > Andrew Chernow <ac@esilo.com> writes:
> >
> > > Installing it per-conn doesn't get you anything.  pqtypes has already
> been linked in.  If you use PQexec and PQgetvalue, the pqtypes code pretty
> much does nothing.  So, a per-conn install seems redundant.  You are
> installing the same function pointers under the same name over and over.  If
> you link with, it should just be available.
> > >
> >
> > I don't really agree with that argument; it's not impossible that you'd
> > want it on some connections and not others.  The server version for
> > instance could affect the choice.
> >
> > Per-conn install also gets you out of a bunch of thread safety issues
> > (because we've already decreed that it's the app's problem to ensure
> > that only one thread touches a PGconn at a time).

>  AFAICS, thread-safety is the big problem. I didn't really like the locking

Maybe if there was PQinitGlobalHooks so that all PGconn structs
created would inherit the hooks automatically...this allows per conn
initialization (if desired) and global initialization which is often
easier.  As I understand this, no locking is required, except the init
function needs to be called before any real libpq code takes place (in
threaded environments).

merlin


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: pulling libpqtypes from queue
Next
From: Bruce Momjian
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add pg_terminate_backend() to allow terminating only a single