From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | <kleptog(at)svana(dot)org>, <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Debian package for freeradius_postgresql module |
Date: | 2006-04-22 16:48:46 |
Message-ID: | 004001c6662c$a3cd74dd$6a01a8c0@valehousing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----Original Message-----
From: "Martijn van Oosterhout"<kleptog(at)svana(dot)org>
Sent: 22/04/06 16:44:33
To: "Dave Page"<dpage(at)vale-housing(dot)co(dot)uk>
Cc: "pgsql-general(at)postgresql(dot)org"<pgsql-general(at)postgresql(dot)org>
Subject: Re: [GENERAL] Debian package for freeradius_postgresql module
> I don't disagree that this is proper use of the API, but I don't think
> the original creators of the functions really considered this use.
Maybe not, but their intent & commit logs are irrelevant as far as end use is concerned - the docs and API are the only things we can reasonably expect users to consider.
> And
> it makes it difficult to introduce an
> alternate SSL library.
Well, hindsight is a wonderful thing :-)
> Don't
worry, psqlODBC will still be able to do it's
> thing...
Yes - 'intended use' or not though, please ensure that a GnuTLS (or implementation agnostic) equivalent to PQgetssl is available so we don't have to dictate library choice to people.
Regards, Dave
-----Unmodified Original Message-----
On Sat, Apr 22, 2006 at 04:30:21PM +0100, Dave Page wrote:
> > Well, you need to be careful here. Just installing GnuTLS support as is
> > will break the latest release of psqlODBC, because they do things with
> > libpq that it wasn't really designed for.
>
> Err, what? It uses PQsocket & PQgetssl, both of which are official,
> supported functions that may be being used by countless other apps
> for all we know. If libpq wasn't designed to allow apps to use the
> socket & SSL struct directly, why include and document the APIs?
AIUI, PQsocket was added back in 6.4 to allow users to do asyncronous
operations. ([1] Tom Lane)
int PQsocket (PGconn *conn);
Returns the Unix file descriptor for the socket connection to the
backend, or -1 if there is no open connection. This is a violation
of modularity, of course, but there is no alternative: an
application that needs asynchronous execution needs to be able to
use select() to wait for input from either the backend or any other
input streams it may have. To use select() the underlying socket
must be made visible.
PQgetssl was added in 2000 ([2] Magnus Hagander) with the comment:
* I added accessor function "SSL *PQgetssl(void)" to libpq,
to get the SSL structure. Any functions from OpenSSL can
then be used on this returned structure to get information.
* Made psql use this PQgetssl() function after initial
connection to report SSL status (only if enabled, of course)
It was added so users could "get information" about the connection, not
to read/write to the connection.
I don't disagree that this is proper use of the API, but I don't think
the original creators of the functions really considered this use. And
it makes it difficult to introduce an alternate SSL library. Don't
worry, psqlODBC will still be able to do it's thing...
[1] http://archives.postgresql.org/pgsql-hackers/1998-04/msg00611.php
[2] http://archives.postgresql.org/pgsql-patches/2000-08/msg00019.php
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2006-04-22 17:13:40 | Re: sudo-like behavior |
Previous Message | Martijn van Oosterhout | 2006-04-22 15:44:30 | Re: Debian package for freeradius_postgresql module |