Re: libpq and prepared statements progress for 8.0

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

> OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
>
> PGresult *
> PQprepare(PGconn *conn,
> const char *stmtName,
> const char *query,
> int nParams,
> const Oid *paramTypes)
> {
> ...
>
> PQprepare would construct a Parse message to create a prepared statement
> named stmtName from the given query, with nParams types pre-declared. It
> could be called by DBD::Pg with nParams == 0 to let the server infer all
> of the parameter types.

You have to have a parameter for specifying the portalName. Since using the
"unnamed" portal is no longer really an option.

That means you also need to add a new Execute method that takes a portalName
instead of a command.

I've been fooling around with this. But don't let that stop you, I haven't
said anything precisely because I figure my odds on getting this finished to
be quite low. And in any case I don't know if it'll be up to snuff for
inclusion.

I have a couple questions:

1) I expect any driver to automatically gensym up all the statement names and
portal names. I wonder whether libpq shouldn't be doing the same thing.
This goes back to the same issue of libpq trying to satisfy two masters. A
C programmer would be happy with libpq gensymming the statement names and
portal names, but a driver author would be just as happy doing it himself.

2) How is it that the error handling in the existing PQsendQueryGuts works at
all?! It just aborts wherever it's at and jumps to a function that
consumes all input. It has no idea where to stop consuming since the SYNC
may or may not have been sent. If there's a network burp wouldn't it cause
messages to get left over to confuse matters for the next call?

I wonder whether it would make sense to have SYNC messages come with an
integer parameter attached which gets echoed back by the server. Then libpq
error handling can just issue its own SYNC and wait until it gets back a SYNC
response with the correct value, rather than have to engineer the sending code
to keep careful track of whether the SYNC has been sent or not.

--
greg