Re: libpq and prepared statements progress for 8.0

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, David Wheeler <david(at)kineticode(dot)com>, Rudy Lippan <rlippan(at)remotelinux(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq and prepared statements progress for 8.0
Date: 2004-09-20 07:34:02
Message-ID: 200409200734.i8K7Y2v00602@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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(at)opencloud(dot)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(at)postgresql(dot)org
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2004-09-20 07:54:23 Re: execve() vs system() for chrooted filesystems in dbcommands.c
Previous Message Abhijit Menon-Sen 2004-09-20 06:32:23 Re: libpq and prepared statements progress for 8.0

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2004-09-20 07:45:28 Re: Translation updates for 8.0: libpq-ru, pg_ctl-ru, pg_dump-ru, psql-ru
Previous Message Serguei Mokhov 2004-09-20 07:27:00 Translation updates for 7.4/8.0: postgres-ru