On Tuesday 03 August 2004 11:46 am, Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > Having done something similar for the SPI manager once, so that
> > parameters can have unknown type and the code calling SPI_prepare()
> > will find the chosen types in the type array, so that the code calling
> > SPI_execp() can do the appropriate type casting, my idea is that
> > preparing a statement does the same and exec prepared actually accepts
> > unknown type arguments and calls the typein function before running the
> > plan. However, I still need to look at the code ...
>
> This is already *done*. All we need is to devise a reasonable API for
> libpq to provide access to the V3-protocol Prepare message. I suspect
> that we'd want it to bundle a Prepare and a Describe Statement
> operation, so that the user would get back the list of actual argument
> types in the same call that issues the prepare. But I haven't thought
> it through in detail.
>
> > If this is doable that way, we could log it as an open issue that needs
> > to be finished for release.
>
> [ shrug ] Arguably it was something that should have been done for 7.4.
> If someone wants to step up to the plate now, I won't stand in the way.
>
As far as API, how about this: (My C is rusty...)
typedef struct PGpreparedStmt { char *name, char *stmt, int nParams, Oid *paramTypes,
} PGpreparedStmt;
PGpreparedStmt *PQprepare(PGconn *, char *name, char *stmt);
We could make the PGpreparedStmt struct opaque to the client (like PGresult
and PGconn) and provide accessor functions.
const char *PQpreparedStmtName(const PGpreparedStmt *);
const char *PQpreparedStmtStmt(const PGpreparedStmt *);
int PQpreparedStmtNParams(const PGpreparedStmt *);
const Oid *PQpreparedStmtParamTypes(const PGpreparedStmt *);
Question: Can we handle asynchronous prepares? (I think we could follow the
notifies method - it just magically picks it up while you consumeInput.)
int PQsendPrepare(PGconn *, char *name, char *stmt);
PGpreparedStmt *PQgetPrepare(PGconn *);
The naming could be better. I can't think of any good alternatives right
now.
I'll look into how to actually implement this at home tonight.
--
Jonathan Gardner
jgardner@jonathangardner.net