Re: PQinitSSL broken in some use casesf

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQinitSSL broken in some use casesf
Date: 2009-02-14 02:46:53
Message-ID: 4996309D.3090802@esilo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-02-14 05:03:42 Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)
Previous Message KaiGai Kohei 2009-02-14 01:32:22 Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)