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

Volkan YAZICI <yazicivo@ttnet.net.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