Volkan YAZICI <[EMAIL PROTECTED]> writes: > On Aug 16 11:37, Tom Lane wrote: >> I think this viewpoint has pretty much carried the day, so the >> PQdescribe functions should remain separate. However, it still seems >> to me that it'd be a shame if PQdescribePrepared couldn't return the >> statement's output column types, seeing that the backend is going to >> pass that info to us anyway.
> I think you have a misunderstanding about the patch I previously sent. > When you issue a PQdescribePrepared() call, in the first PQgetResult() > call returned PGresult will have the input parameter types of the > prepared statement. And in the second PQgetResult() call, returned > PGresult will hold statement's output column types. [ raised eyebrow... ] You're right, I didn't understand that, and now that I do I find it completely unacceptable. We need exactly one PGresult per operation, or things just get too weird for clients to manage, particularly when considering async behavior. What you suggest is a *huge* violation of the principle of least surprise. Adding a couple more PGresult accessor functions seems far saner. > Another possibility can be like this: > PGresult *PQdescribePrepared(PGconn *conn, > const char *stmt, > Oid **argtypes); No, because that doesn't work at all for the async case. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match