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

On Aug 16 11:37, Tom Lane wrote:
> Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr> writes:
> > On Aug 11 12:51, Greg Sabino Mullane wrote:
> >> Prepared statements are not visible nor survivable outside of your
> >> session, so this doesn't really make sense. If your application needs
> >> the information, it can get it at prepare time.
>
> > What about persistent connections? Actually, I can give lots of corner
> > cases to support my idea but they're not that often used. I think, as
> > long as we'll break compatibility, placing Describe facility in the
> > PQprepare() is not the way to go.
>
> 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.

> So I propose storing the parameter type
> info in a new section of a PGresult struct, and adding new PGresult
> accessor functions PQnparams, PQparamtype (or maybe PQptype to follow
> the existing PQftype precedent more closely) to fetch the parameter type
> info. The existing functions PQnfields etc will fetch output-column
> info. Aside from being more functional, this definition maintains the
> principle of least surprise, in that the interpretation of a PGresult
> from Describe isn't fundamentally different from a PGresult from a
> regular query.

Another possibility can be like this:

PGresult *PQdescribePrepared(PGconn *conn,
const char *stmt,
Oid **argtypes);

A PQdescribePrepared() call will immediatly return a PGresult
(previosly, we were just returning a boolean value that shows the result
of the command send status) result that holds statement's output column
types and argtypes will get altered to point to an Oid array that has
input parameter type information. (By assigning NULL value to argtypes,
user will decide to receive or not receive input parameter types.)

> We also need async versions PQsendDescribePrepared and
> PQsendDescribePortal, as I mentioned before.

If you decided on the method to use I'm volunteered to modify existing
patch. Waiting for your comments.

Regards.