Re: libpq and prepared statements progress for 8.0
От | Bruce Momjian |
---|---|
Тема | Re: libpq and prepared statements progress for 8.0 |
Дата | |
Msg-id | 200409200734.i8K7Y2v00602@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: libpq and prepared statements progress for 8.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpq and prepared statements progress for 8.0
|
Список | 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 по дате отправления: