Tom Lane wrote:
> Magnus Hagander <magnus@hagander.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/
