On Fri, Jul 21, 2006 at 04:14:52PM +0300, Volkan YAZICI wrote:
> On Jul 21 09:02, Jacob Coby wrote:
> > Volkan YAZICI wrote:
> > >As Tom mentioned, there's support for this feature in the protocol
> > >level, but I don't know any API supports this yet. However, here's a
> > >patch that adds Describe functionality for Prepared Statements and
> > >Cursors to libpq:
> > >http://archives.postgresql.org/pgsql-hackers/2006-06/msg01281.php
> >
> > PHP supports it with the pg_field_type() function.
>
> PHP uses libpq in the background to communicate with the server. How
> can you wait PHP to support a feature that's not supported by libpq?
> Furtheremore, pg_field_type() queries system catalogs to collect
> information which is quite different than Describe functionality.
Really, I would have thought the PHP function would map directly to the
libpq PQftype() function. Although libpq returns the OID whereas the
PHP function returns the type. But I don't think that's what the
original user asked for given you need a ResultSet first.
This is kind of related to the "feature" of libpq that it won't give
you a resultset until the query is complete.
Note: this isn't entirely true, you can do a PQgetResult on an
asyncronous query while it is not yet finished and look at the partial
resultset. I used this in my mvcctest program to be able to track
exactly how far info a resultset it blocked. I wonder if you could send
the query asyncronously and then consume input until you get the
header. At least it'll give you the info before running the whole
query... It doesn't give you it at prepare stage though.
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.