Re: Prepared queries and portals - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Prepared queries and portals
Date
Msg-id 19393.1078358485@sss.pgh.pa.us
Whole thread Raw
In response to Prepared queries and portals  ("Cyril VELTER" <cyril.velter@metadys.com>)
List pgsql-hackers
"Cyril VELTER" <cyril.velter@metadys.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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: [PERFORM] WAL Optimisation - configuration and usage
Next
From: "Alex J. Avriette"
Date:
Subject: Re: Slony-I makes progress