> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org 
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Wednesday, September 15, 2004 10:51 AM
> To: Greg Stark
> Cc: Merlin Moncure; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0 
> 
> 
> Greg Stark <gsstark@mit.edu> writes:
> > Is there anything technically hard in adding this functionality to 
> > libpq? It looks like it's just mechanically adding more 
> entry points 
> > to existing code.
> 
> Well, (a) I ran out of time, and (b) I wasn't sure what the 
> most convenient API would be.  Should we create something 
> that packages together a Parse and a Describe Statement, or 
> expose those as separate things?
> 
> There's surely no technical difficulty once you've got some 
> consensus on what the API should look like.
> 
> > The describe statement part could be much trickier but 
> DBD::Pg doesn't 
> > really need that for basic functionality.
> 
> Doesn't it?  I thought the problem was that they couldn't 
> find out what datatypes the parameters got resolved as.  That 
> may not be important if they are happy with always shipping 
> text strings, but if they want to move over to using binary 
> transmission of parameter values then they gotta know the 
> parameter types.
> 
> > I do wonder whether DBD::Pg is really best off using libpq.
> 
> I was wondering that myself.  Would they be able to implement 
> a pure-Perl driver if they ginned up their own protocol code? 
> It'd be a lot of work, of course, so I can understand that 
> they might not feel it's worth the trouble.
> 
> > From what I'm reading now it seems the "read every record before 
> > returning" behaviour is rooted in the libpq interface.
> 
> Right.  Again that's probably something that could be handled 
> by exposing more/different API, but no one has stepped up to 
> design it.

What about using ECPG as an interface for drivers?

I wrote an ODBC driver for Rdb on OpenVMS using SQLMOD (which is
[essentially] ECPG for Rdb) so that is a technique that should be able
to provide the needed functionality.

According to my understanding ECPG is now reentrant.  Is that correct?

Wed, 15 Sep 2004 11:02:20 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: libpq and prepared statements progress for 8.0 
"Dann Corbit" <DCorbit@connx.com> writes:
> What about using ECPG as an interface for drivers?

What for?  It's not a substitute for libpq --- it sits on top of libpq,
or did last I checked anyway.  And it's designed around a preprocessor
that seems fairly useless for a driver.

			regards, tom lane

Wed, 15 Sep 2004 14:11:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq and prepared statements progress for 8.0 

Tom Lane <tgl@sss.pgh.pa.us> writes:

> "Dann Corbit" <DCorbit@connx.com> writes:
> > What about using ECPG as an interface for drivers?
> 
> What for?  It's not a substitute for libpq --- it sits on top of libpq,
> or did last I checked anyway.  And it's designed around a preprocessor
> that seems fairly useless for a driver.

As it happens DBD::Oracle does use Oracle's precompiler. But it's more of a
hindrance than a help. It basically has to define and implement its own API
which is compiled with Pro*C. Then the rest of the codebase can ignore the
precompiler and use that interface. 

Precompilers are really old school. There's not much point to using them
except in legacy applications that need them. They offer no advantage over a
programmatic API, and lots of disadvantages. You have to learn a new language,
you're one step further removed from the resulting code, and heaven help you
if your compiler version doesn't match what the precompiler was tested with.
Nevermind actually trying to use it from another language entirely.


-- 
greg


15 Sep 2004 14:33:34 -0400
Greg Stark <gsstark@mit.edu>
Re: libpq and prepared statements progress for 8.0