Re: PQinitSSL broken in some use casesf

Поиск
Список
Период
Сортировка
От Andrew Chernow
Тема Re: PQinitSSL broken in some use casesf
Дата
Msg-id 4996309D.3090802@esilo.com
обсуждение исходный текст
Ответ на Re: PQinitSSL broken in some use casesf  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: PQinitSSL broken in some use casesf  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)