Re: libpq and prepared statements progress for 8.0

Abhijit Menon-Sen <ams@oryx.com> writes:

> At 2004-09-20 01:25:56 -0400, gsstark@mit.edu wrote:
> >
> > That means you also need to add a new Execute method that takes a
> > portalName instead of a command.

Oh, it occurs to me I missed a step in my earlier logic. I assumed we would
want a separate Bind and execute call. Do we? I think we do, but the only
advantages are pretty thin:

1) It could be convenient to have an application call bind but have another  layer call execute. I've never seen this
happen.

2) If we ever want to implement a Describe call then it would have to happen  between Bind and execute. Personally I
findit annoying that you can't call  describe on a statement, only a portal, but that's the way it is now.
 


> Yes, thanks. How about these functions, then?
> 
>     PGresult *
>     PQprepare(PGconn *conn,
>               const char *stmtName,
>               const char *query,
>               int nParams,
>               const Oid *paramTypes);
> 
>     PGresult *
>     PQbind(PGconn *conn,
>            const char *stmtName,
>            const char *portalName,
>            int nParams,
>            const char *const *paramValues,
>            const int *paramLengths,
>            int nFormats,
>            const int *paramFormats,

>            int nResults,
>            const int *resultFormats);

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


>     PGresult *
>     PQexecute(PGconn *conn,
>               const char *portalName,
>               int nRows);

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

-- 
greg