 

> -----Original Message-----
> From: Dave Cramer [mailto:pg@fastcrypt.com] 
> Sent: 17 September 2004 14:52
> To: Dave Page
> Cc: Greg Stark; Oliver Jowett; Tom Lane; Merlin Moncure; 
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
> 
> Interesting,
> 
> I'd like to know more about the issues you are trying to 
> solve? Seems counter productive for all of us to attempt this 
> independently

Mainly lack of time :-)

SSL and v3+ protocol support are the primary issues. If we can use
libpq, then obviously we don't have to worry about them any more. Other
than that, there isn't then a great deal left to do with the driver
(that I can think of) as the vast majority of the API is there and
working, and we have unicode support as well now.

> What about the .net driver ? Yet another protocol implementation ?

Yeah, native, managed C# code.

Regards, Dave

Fri, 17 Sep 2004 14:56:09 +0100
"Dave Page" <dpage@vale-housing.co.uk>
Re: libpq and prepared statements progress for 8.0
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> From: Dave Cramer [mailto:pg@fastcrypt.com] 
>> I'd like to know more about the issues you are trying to 
>> solve? Seems counter productive for all of us to attempt this 
>> independently

> Mainly lack of time :-)

> SSL and v3+ protocol support are the primary issues. If we can use
> libpq, then obviously we don't have to worry about them any more.

Another point is that since the ODBC driver is C anyway, there are no
cross-language issues for it in relying on libpq.  This is quite
different IMHO from the situation for JDBC, or DBD::Pg, where there are
advantages in having a single-language solution.

BTW, there is also a pure-Tcl client implementation out there, written
despite the pre-existence of a version sitting atop libpq.  Same story:
needing some C code reduces portability, or at least ease of installation.

			regards, tom lane

Fri, 17 Sep 2004 10:36:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq and prepared statements progress for 8.0 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
> Another point is that since the ODBC driver is C anyway, there are no
> cross-language issues for it in relying on libpq.  This is quite
> different IMHO from the situation for JDBC, or DBD::Pg, where there are
> advantages in having a single-language solution.
 
This is not so much of an issue with DBD::Pg - it already uses quite a
bit of C code[1]. not only from libpq, but because DBI is written in C, and
because it is handy sometimes to use non-libpq pgsql code, such as some
of the quoting stuff. Having libpq is definitely a bonus for us (DBD::Pg),
and we've never really had an issue with libpq until now, and it's getting
fixed, so no worries.
 
[1] Well, C and pseudo-C XS code anyway.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200409202318
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFBT52RvJuQZxSWSsgRAvWXAJ9FTLnVzFULYKEF1Z16EnNJw6BxewCdFHW5
13hbl5M6pT9+oezDpAVetIM=
=Dpjb
-----END PGP SIGNATURE-----



Tue, 21 Sep 2004 03:18:04 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: libpq and prepared statements progress for 8.0 