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

From Abhijit Menon-Sen
Subject Re: libpq and prepared statements progress for 8.0
Date
Msg-id 20040920081508.GB5441@penne.toroid.org
Whole thread Raw
In response to Re: libpq and prepared statements progress for 8.0  (Greg Stark <gsstark@mit.edu>)
Responses Re: libpq and prepared statements progress for 8.0  (Greg Stark <gsstark@mit.edu>)
Re: libpq and prepared statements progress for 8.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)

At 2004-09-20 02:16:50 -0400, gsstark@mit.edu wrote:
>
> I assumed we would want a separate Bind and execute call. Do we?

Yes, we do. (See below.)

> Personally I find it annoying that you can't call describe on a
> statement, only a portal, but that's the way it is now.

No, it isn't. Describe accepts both prepared statement and portal names.
In the former case, it returns ParameterDescription message as well as
the RowDescriptions it returns for the latter.

> resultFormat is just a single integer in the protocol. You don't get
> to specify different formats for different columns.

Yes, you do. Bind accepts 0 (use the default text format), 1 (use this
format for all results), or as many result format specifiers as there
are results.

> What's nRows? None of the existing PQexec* take an nRows parameter.

Execute can be told to return no more than n rows of results. If there
are more rows available, the server returns PortalSuspended and awaits
another Execute message. The default of 0 imposes no limit.

Because it's sometimes required to call Execute without Binding values
again, libpq needs separate bind/execute functions to support this.

Please read protocol-flow.html and protocol-message-formats.html.

-- ams


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: execve() vs system() for chrooted filesystems in dbcommands.c
Next
From: "Andrew Dunstan"
Date:
Subject: Re: execve() vs system() for chrooted filesystems in dbcommands.c