Volkan YAZICI <[EMAIL PROTECTED]> 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...)
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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
