Re: libpq and prepared statements progress for 8.0

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <gsstark(at)mit(dot)edu>
Cc: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq and prepared statements progress for 8.0
Date: 2004-09-15 18:02:20
Message-ID: D425483C2C5C9F49B5B7A41F89441547055497@postal.corporate.connx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Sent: Wednesday, September 15, 2004 10:51 AM
> To: Greg Stark
> Cc: Merlin Moncure; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
>
>
> Greg Stark <gsstark(at)mit(dot)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?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-09-15 18:11:55 Re: libpq and prepared statements progress for 8.0
Previous Message Tom Lane 2004-09-15 17:50:43 Re: libpq and prepared statements progress for 8.0