Re: PQinitSSL broken in some use casesf - Mailing list pgsql-hackers

From Andrew Chernow
Subject Re: PQinitSSL broken in some use casesf
Date
Msg-id 4996309D.3090802@esilo.com
Whole thread Raw
In response to Re: PQinitSSL broken in some use casesf  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PQinitSSL broken in some use casesf  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
So far, we have the below ideas:

1. void PQinitSSL(MAGIC_VALUES)
The idea is to use some magic values to add more options, converting the do_init 
argument from a flag to an enumeration.  The idea is choose magic values that 
would most likely never be used by existing libpq applications.  The downside to 
this method is there is no way to detect if the request was honored: meaning a 
new app passes a magic value to an older libpq.

2. void PQinitSecure(int init_ssl, int int_crypto)
Another proposed name was PQinitSSLExtended or PQinitOpenSSL.  This leaves the 
existing PQinitSSL alone.  The problem here is that it can't be extended like 
the current PQinitSSL, so we fixed today's problem but created it again for 
future (sounds like government).  That leads us to #3.

3. void PQinitSecure(int init_mask)
Works just like #2 but uses a bit mask, like PG_INITSSL or something, instead of 
a fixed set of flags.  It trys to make the function more extendable.  Although, 
we bang into the #1 problem again - new apps using new bits that older libpqs 
are not aware of.  There is no way to know if the request was honored.  This 
leads us to #4 (#5 was also a suggested fix).

4. int PQinitSecure(int init_mask)
This works just like #3 but returns the bits it understood.  It allows an app to 
determine if the loaded libpq supports a bit it has tried to use.  I have not 
heard any comments on this, I am still looking for its faults.  You could claim 
its akward, but I've seen much worse.  An alternative is to add a second 
argument, int *support_mask, instead of returning it.  Or, make the single 
argument an input and output value .. (int *mask).

5. ??? PQgetLibraryVersion(???)
Another proposed name was PQversion.  This was suggested as a way of fixing the 
faults of #1 and #3.  The idea is to use the libpq version to determine if a 
particular init bit is supported.

6. PQinit(int init_who, void *data)
Revived from a recent WSACleanup thread.  Appears to always be the last kid 
picked for the kick ball team, so I won't dive to deep.  The idea is to create a 
single init function for libpq, that can handle init'n any 
module/feature/runtime-settings/etc..  Another name could be PQcontrol.

I think that's everything.  Are there any favorites or combos?  Personally, I'm 
not really stuck on any of them.  I'd just like to see the feature added.  If I 
had to choose, it would be #4.  A close second would be #1 + #5 (using PQversion 
as the name).

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)
Next
From: Jaime Casanova
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)