Re: libpq Describe Extension [WAS: Bytea and perl] - Mailing list pgsql-hackers

On Aug 10 11:35, Tom Lane wrote:
> Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> > [ patch to add PQdescribePrepared and PQdescribePortal ]
> 
> After looking this over, I don't see the point of PQdescribePortal,
> at least not without adding other functionality to libpq.  There is
> no functionality currently exposed by libpq that allows creating a
> portal (that is, sending a Bind message) without also executing the
> portal.  And the execution always returns the portal description.
> So I don't see why you'd use it.
> 
> PQdescribePrepared is useful though, as it plugs the feature omission
> mentioned in the description of PQprepare, namely, you can't find out
> what datatype was inferred for a parameter that you didn't specify a
> type for.
> 
> My inclination is to add PQdescribePrepared, but leave out
> PQdescribePortal until such time as we decide to add functions
> to libpq that support separate Bind and Execute operations.
> (That might be never, seeing that no one's gotten around to it
> since 7.4...)

My intention while implementing PQdescribePortal() was to gather
information about a portal created by an explicit DECLARE ... CURSOR
query. In case of connections are persistenly established with some pool
mechanism, it can be handy to be able to learn will be returned row
descriptions from an existing portal.

> The patch is missing an asynchronous version of PQdescribePrepared.
> I'm not real sure what to call it --- the naming conventions we've
> used in libpq are not as orthogonal as one could wish.
> PQsendDescribePrepared is the best I can manage; anyone have a better
> idea?
> 
> Also, we could take a completely different tack, which is to not invent
> new functions but instead fold this functionality into PQprepare and
> PQsendPrepare.  What Volkan's done with this patch is to define the
> successful result of PQdescribePrepared as being a PGresult in which
> only the number of columns and their datatypes (PQnfields and PQftype)
> are meaningful.  We could perfectly well use that convention in the
> PGresults returned by PQprepare/PQsendPrepare.  The upside of this
> method is that it wouldn't require an extra network round trip to get
> the information (because we'd just include the Describe Statement
> request in the original Prepare packet).  The downside is that we'd
> always spend the time to perform Describe Statement, even if the
> application doesn't need it.  However I'd expect that time to be
> pretty minimal in comparison to the other costs of a Prepare.
> 
> I'm leaning slightly to the fold-it-into-PQprepare way, but am by
> no means set on that. Comments anyone?

IMHO, it isn't the only use case of Description messages for prepared
queries to learn the infered types just after a PQprepare() call. I
think it would be quite handy to be able to gather information about a
prepared stmt in later phases of an application. For instance one might
need to get the parameter and row types of a prepared query that he/she
isn't created. If we'd place Describe message facility into PQprepare(),
then we'll just lose that functionality of the feature.

OTOH, moving Describe data processing into the PQprepare() is fairly
conventional for introducing a new functionality at the same time
keeping the API consistent without raising any compatibility problems.
But AFAICS, that's not possible without giving over one of the features
of Describe messages for prepared statements: parameter types
information or row types information. Because, if we consider placing
Describe facility into PQprepare(), client would have to issue two
distinct PQgetResult() calls; one for parameter types and another one
for row types.

On Aug 10 12:31, Tom Lane wrote:
> So another theory about how this ought to work is that PQprepare's
> result PGresult ought to carry the column name/type info where PQfname
> and PQftype can get them, and then we'd have to have two new
> PGresult-inspection functions to pull out the separately stored
> parameter-datatype info.

Yes, that's another feasible approach to the solution. But this one too
has its own PITAs as the one mentioned above.

> This seems much cleaner than overloading the meaning of PQftype, but
> OTOH it's yet a few more cycles added to the execution cost of
> PQprepare.

I think, placing Describe facility into PQprepare() will just obfuscate
the problem. In every approach we tried to place Describe into
PQprepare(), we needed to introduce new functions or broke compatibility
with the exisiting versions. ISTM, Describe features having their own
functions is the only fair solution I could come up with.

> Anyone have a need to get the result type info during PQprepare?

I don't think so. And if one would ever need such an information, can
reach it quite easily via PQdescribePrepared().


Regards.