Re: libpq Describe Extension [WAS: Bytea and perl]

Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> 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