Re: libpq and prepared statements progress for 8.0 - Mailing list pgsql-hackers

From David Wheeler
Subject Re: libpq and prepared statements progress for 8.0
Date
Msg-id 512571EA-08E6-11D9-9CAB-000A95B9602E@kineticode.com
Whole thread Raw
In response to libpq and prepared statements progress for 8.0  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: libpq and prepared statements progress for 8.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: tweaking MemSet() performance - 7.4.5
Next
From: Tom Lane
Date:
Subject: Re: Disabling bgwriter on my notebook