Bruce Momjian wrote:
> Andrew Chernow wrote:
>> Bruce Momjian wrote:
>>> Andrew Chernow wrote:
>>>> Bruce Momjian wrote:
>>>>> Ah, OK, so it does its own cleanup on last close, great. I agree a
>>>>> connection option for this would be good.
>>>>>
>>>> What would the option be? "wsainit = [enable | disable]"? Maybe it
>>>> should allow setting the version to load: "wsa_version = 2.0". Maybe
>>>> the two should be combined: "wsa_version = [default | disable | 2.0]".
>>> I assumed it would be like SSL, which is a libpq function call, not a
>>> connection option, e.g. PQinitSSL(), and I think true/false is probably
>>> enough. PQinitSSL info:
>>>
>>> If you are using <acronym>SSL</> inside your application (in addition
>>> to inside <application>libpq</application>), you can use
>>> <function>PQinitSSL(int)</> to tell <application>libpq</application>
>>> that the <acronym>SSL</> library has already been initialized by your
>>> application.
>>>
>> That smells dirty to me. How many PQinitXXX() functions are needed
>> before we drop the XXX and run with PQinit(...)?
>
> Odds are you would still need per-library control over initialization so
> I am not sure that helps, i.e. the library initialized WSA already but
> needs SSL.
>
That's fine. I solved that issue here:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01349.php
One of arguments is an "options" bit mask. PG_OPT_LOADSSL,
PG_OPT_LOADWSA, etc... I also suggested a "int inittype, void
*initdata" arguments that can be used now or for future expansion; that
way PQinit is not limited to a single int argument. This could be used
right away with the PG_OPT_LOADWSA idea, to pass the wsa version you want.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
