Re: pulling libpqtypes from queue

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: pulling libpqtypes from queue
Дата
Msg-id b42b73150804151229x68673c95x790cc7d4c5d5fc5b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pulling libpqtypes from queue  (Andrew Chernow <ac@esilo.com>)
Ответы Re: pulling libpqtypes from queue  (Andrew Chernow <ac@esilo.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Chernow
Дата:
Сообщение: Re: pulling libpqtypes from queue
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Add pg_terminate_backend() to allow terminating only a single