Re: Debian package for freeradius_postgresql module

-----Original Message-----
From: "Martijn van Oosterhout"<kleptog@svana.org>
Sent: 22/04/06 16:44:33
To: "Dave Page"<dpage@vale-housing.co.uk>
Cc: "pgsql-general@postgresql.org"<pgsql-general@postgresql.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
onlythings 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
availableso 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@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.