From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq WSACleanup is not needed |
Date: | 2009-01-18 20:20:25 |
Message-ID: | 49738F09.9070605@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Yeah. So the question is, do we want to bite the bullet and create
>> init() and uninit() functions for libpq?
>
> I think if calling them is an optimization that improves performance
> (by eliminating per-connection-start overhead), this could fly. If
> the plan is "we are going to require applications to call these
> or they'll break", it's not going to be acceptable ...
>
> regards, tom lane
>
My suggestion was to make calling the init/uninit optional (well uninit should
only be optional if init was not called). I think libpq should behave
identically if init() is never called. What init() gets you is the ability to
fine tune libpq (change the default behaviors). For instance: a bit mask
argument to init() called "options", that allows one to toggle things on/off in
libpq: like PG_OPT_NOWSAINIT or PG_OPT_NOSSLINIT. It may requrie something like
to be expandable:
int
PQinit(int info_type, void *info_struct, int options);
I'm just spit-ball'n here. My point is, its could be a good place to allow run
time configuration of libpq.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2009-01-18 20:45:50 | Re: libpq WSACleanup is not needed |
Previous Message | Peter Eisentraut | 2009-01-18 20:16:23 | Re: Fixes for compiler warnings |