On Thu, Aug 10, 2006 at 12:31:52PM -0400, Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> 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?

David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to