Re: libpq and prepared statements progress for 8.0

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