"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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
