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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
