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
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 |
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 |