Re: libpq WSACleanup is not needed

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/

In response to

Browse pgsql-hackers by date

  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