Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Aug 11 12:51, Greg Sabino Mullane wrote:
>> Prepared statements are not visible nor survivable outside of your
>> session, so this doesn't really make sense. If your application needs
>> the information, it can get it at prepare time.
> What about persistent connections? Actually, I can give lots of corner
> cases to support my idea but they're not that often used. I think, as
> long as we'll break compatibility, placing Describe facility in the
> PQprepare() is not the way to go.
I think this viewpoint has pretty much carried the day, so the
PQdescribe functions should remain separate. However, it still seems
to me that it'd be a shame if PQdescribePrepared couldn't return the
statement's output column types, seeing that the backend is going to
pass that info to us anyway. So I propose storing the parameter type
info in a new section of a PGresult struct, and adding new PGresult
accessor functions PQnparams, PQparamtype (or maybe PQptype to follow
the existing PQftype precedent more closely) to fetch the parameter type
info. The existing functions PQnfields etc will fetch output-column
info. Aside from being more functional, this definition maintains the
principle of least surprise, in that the interpretation of a PGresult
from Describe isn't fundamentally different from a PGresult from a
regular query.
We also need async versions PQsendDescribePrepared and
PQsendDescribePortal, as I mentioned before.
Anyone have different suggestions for the names of these functions?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
