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
