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? Cheers, D -- 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
