Re: libpq and prepared statements progress for 8.0

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> > Question: what is the relevance of the binary protocol, are you trying
> > to send/fetch binary data via the command interface?
>
> My understanding of the original post is that DBD::Pg is sitting atop
> libpq and wants to keep doing so. So they're going to need some
> improvements to libpq to get at Parse-into-a-named-statement and
> Describe Statement. This is one of the things that didn't get done in
> the 7.4 cycle, and no one seems to have got round to it later either.
> But it's clearly a deficiency of libpq.

Well even without parse-into-a-named-statement they could be using PQexecParam
for now. I'm talking with them trying to straighten this out.

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.
Were you leaving this as a honey pot hoping it would attract new programmers?
I'm looking at doing it now.

The describe statement part could be much trickier but DBD::Pg doesn't really
need that for basic functionality. It would be a useful feature for later
though.

I do wonder whether DBD::Pg is really best off using libpq. From what I'm
reading now it seems the "read every record before returning" behaviour is
rooted in the libpq interface. Ideally a program should be able to stream
results and process them as they arrive. It looks like PQgetResult might be
relevant but the documentation isn't clear whether each result returned is for
an entire query in the original statement or if they can be partial result
sets.

--
greg