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
|
Список | 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 по дате отправления: