Re: libpq and prepared statements progress for 8.0

Abhijit Menon-Sen <ams(at)oryx(dot)com> writes:

> (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(at)mit(dot)edu wrote:
> >
> > I assumed we would want a separate Bind and execute call. Do we?

I forgot the main reason I assumed this. Namely that drivers have to provide
this interface. If we don't provide it in libpq then they have to emulate it
by storing the parameters until execute time.

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

I see this now. I didn't realize you got back both sets of information when
describing a statement. Does Binding get any useful feedback? Does it tell you
at that time if the text input can't be parsed as the appropriate types for
example?

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

Ooh, I was just looking at the existing code. This is indeed in the protocol
specs.

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

So this is the strongest argument for separating bind and execute. If you
didn't you would still need a second call executeContinue or something.

--
greg