"Cyril VELTER" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
