Re: libpq and prepared statements progress for 8.0 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: libpq and prepared statements progress for 8.0
Date
Msg-id 200409200734.i8K7Y2v00602@candle.pha.pa.us
Whole thread Raw
In response to Re: libpq and prepared statements progress for 8.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq and prepared statements progress for 8.0  (David Wheeler <david@kineticode.com>)
List pgsql-hackers
There was some previous discussion of whether DBD:pg should continue
using libpq or implement the wire protocol in Perl, and whether ODBC
should move to using libpq.

I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for jdbc/java.
I think having all interfaces take advantage of libpq improvements and
features is a major win.  If we need to add things to libpq to make it
easier, fine, but that is minor work compared to maintaining separate
wire protocol for each interface language.

---------------------------------------------------------------------------

Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
> > Tom reckons that PREPARE (at the SQL level) taking unknown types is not 
> > useful as there is no feedback mechanism along the lines of the V3 
> > protocol Describe messages to let the client find out what types were 
> > inferred by the PREPARE.
> 
> > I am saying this doesn't matter as the client can still use the 
> > resulting statement just fine without knowing the types. So allowing 
> > 'unknown' in PREPARE *is* useful.
> 
> Well, that was not quite my point, but I guess I wasn't clear.  My
> reasoning was more like this:
> 1. What we have now doesn't do what DBD::Pg needs.
> 2. We can fix it with some-small-amount-of-work in libpq (to add some API),
>    or with some-probably-also-small-amount-of-work in the backend (to
>    kluge up SQL PREPARE to allow "unknown").
> 3. The libpq-side solution is more generally useful, because it can support
>    feedback about the resolved datatypes.
> 4. Therefore, we should fix it in libpq.
> 
> Note that point 3 is not dependent on whether DBD::Pg in particular
> needs this functionality --- somebody out there certainly will.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: libpq and prepared statements progress for 8.0
Next
From: "Magnus Hagander"
Date:
Subject: Re: execve() vs system() for chrooted filesystems in dbcommands.c