Re: libpq and prepared statements progress for 8.0

On Wed, 15 Sep 2004 13:50:43 -0400, Tom Lane wrote:

> > 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 just finished reading through this thread in the archives, and just
wanted to jump in here for a moment, if I could, to ask a couple of
questions to get a few things straight, at least in my mind.

To get initial PREPARE support, I don't think that the other DBD::Pg
developers mind sending strings to the PostgreSQL server in a SQL
PREPARE statement. I certainly don't. It will be great when the binary
API is there in libpq to exploit, but until it is, strings are fine.
This is how DBD::Oracle works, for what it's worth (it sends VARCHAR
bound parameters to the server, and the server figures out the
appropriate data type).

The question, in my mind, is it currently possible to do this without
specifying the type of every placeholder? As Greg Stark points out, it
would be nice to have an API to get this information from the server,
but it's not really important in the short run if the server just takes
care of unknowns. I'm told that it does, but no one has been able to
help us with the syntax, AFAIK.

What we want, I think, is what Greg Stark asks about here:

http://archives.postgresql.org/pgsql-hackers/2004-09/msg00399.php

And Greg Sabino Mullane was asking about the appropriate syntax here:

http://archives.postgresql.org/pgsql-hackers/2004-09/msg00372.php

If we could just get this figured out and know that we can rely on the
server to determine the appropriate syntax for this, we'll have what we
need to get PREPAREd statements working in the next release of DBD::Pg.
Something like this (although this doesn't seem to work):

PREPARE st(unknown) AS INSERT INTO foobar(a) VALUES ($1::unknown);

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

I think that would be great, but I'm hoping it's not required to solve
our immediate problem.

Regards and thanks for the help,

David