On 08/19/2014 10:31 PM, Robert Haas wrote:
On Tue, Aug 19, 2014 at 3:16 PM, Magnus Hagander <mag...@hagander.net> wrote:
On Tue, Aug 19, 2014 at 9:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Magnus Hagander <mag...@hagander.net> writes:
On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmh...@gmail.com> wrote:
I have a hard time believing that something like this will really
satisfy anyone. Why not just add PQgetSchannelHandleOrWhatever() and
call it good? We can try to be incredibly thorough in exposing the
information people want and we will still inevitably miss something
that someone cares about; worse, we'll spend an awful lot of time and
energy along the way.
Well, for one you push the full burden onto the application.
Robert's got a point though: there is always going to be somebody who
wants something we fail to expose. It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed". So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support. There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.
This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc. Just that having an escape hatch isn't a bad thing.
Yeah, wouldn't hurt I guess.
I do agree tha thaving both would be useful. We could have something like
int PQgetSSLstruct(void **sslstruct)
I think it's likely smarter to have totally separate functions.
First, to make it less likely that users will try to use a pointer to
one type of object as a pointer to some other kind of object. And
second, because you might, for example, someday have an SSL
implementation that wants to return two pointers. May as well make
that kind of thing easy.
The struct it returns is totally SSL-implementation specific anyway, so
for an implementation that would like to return two structs, you could
well define it to return a struct like:
struct {
CoolStructA *a;
CoolStructB *b;
} CoolSSLStruct;
I don't much like adding a separate function for every SSL
implementation, but you've got a point that it would be nice to make it
difficult to call PQgetSSLstruct() and just assume that the returned
struct is e.g an OpenSSL struct, while it's actually something else.
Perhaps:
int PQgetSSLstruct(void **sslstruct, char *structname)
You'd call it like PQgetSSLStruct(&mystruct, "openssl"), and it checks
that the argument matches the library actually been used, otherwise it
returns an error. And if you need to return two structs, you'd call it
twice: PQgetSSLStruct(&a, "cool_a") and PQgetSSLStruct(&b, "cool_b").
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
