Re: libpq and prepared statements progress for 8.0

Abhijit Menon-Sen <ams(at)oryx(dot)com> writes:

> At 2004-09-20 01:25:56 -0400, gsstark(at)mit(dot)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 find it 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