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