On Thu, Aug 10, 2006 at 12:31:52PM -0400, Tom Lane wrote:
> "Greg Sabino Mullane" <greg@turnstep.com> writes:
> >> I'm leaning slightly to the fold-it-into-PQprepare way, but am by
> >> no means set on that. Comments anyone?
>
> > As a heavy user of libpq via DBD::Pg, +1 to folding in.
>
> Another thought: I looked into the protocol description and was
> reminded that Describe Statement actually returns both
> ParameterDescription and RowDescription, ie, both the list of
> parameter datatypes and the list of column names and types that will
> be returned by the eventual execution of the statement. 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. 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. Anyone have a need to get the
> result type info during PQprepare?
It could be handy. Perhaps a different version (or different options
to) PQprepare for those who do?
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter
Remember to vote!
