Re: Prepared queries and portals

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "Cyril VELTER" <cyril(dot)velter(at)metadys(dot)com> writes:
> > so I've modified libpq to handle the case by adding to functions :
>
> >
PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt
> > h,paramFormats,resultFormat,maxrows);
>
> > and
>
> > PQfetchPortal(conn,portalName,maxrows)
>
> > PQexecPreparedPortal is a PQexecPrepared clone but you can specify
the
> > portal in which the result should be put (which might be the unnamed
one)
> > and the maximum number of rows to retreive after the execution.
>
> > PQfetchPortal fetch the next rows.
>
> > This works nicely.
>
> This looks fairly messy to me. Seems like the exposed API ought to be
> three functions: set up a portal, fetch (up to) N rows from a portal,
> close down a portal. Your proposal confuses the first two and fails to
> provide the last.

What do you think of :

PQportalSetup(conn,stmtName,portalName,nParams,paramValues,paramlength,param
Formats,resultFormat);

Setup a portal (might be the unnamed one) base on a prepared statement.
return an empty resultset.

PQportalFetch(conn,portalName,maxrows);

Fetch rows from the portal. Return a resultset (empty when finished)

PQportalClose(conn,portalName);

Close the portal, return an empty resultset.

>
> More generally it might be a good idea to provide lower-level access to
> other parts of the extended-query protocol, such as Describe and Sync.
> I did not do anything about that in 7.4 for lack of time, but it's still
> something that ought to be thought about.

Would be nice. One thing that is missing today is the ability to specify
differents format (text/binary) for each columns. Binary bindings are very
nice (performance wise) for bytea and simple datatypes (int/float), but are
not very easy to deal with for complex ones (numeric come to mind). Speaking
of the numeric datatype, does the binary representation can be considered
stable or is it something that will change from version to version ?

Do you think that adding the previous three intermediate-level calls
might be usefull ?

Cyril