On Jul 21 03:34, Martijn van Oosterhout wrote:
> 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.
Maybe, it's time to consider that Describe functionality for libpq
again. Lot's of applications currently rely on libpq to communicate
with the server. And IMHO, any application will be happy to benefit from
a function to query portal headers without requiring a whole result set.
> This is kind of related to the "feature" of libpq that it won't give
> you a resultset until the query is complete.
>
> ... 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.
AFAICS, that's not possible with current parsing capabilities. See
related lines in
fe-protocol3.c:pqParseInput3()
102 /*
103 * Can't process if message body isn't all here yet.
104 */
But, IMNSHO, we can modify parsing functionality to process message
parts step by step. For instance, in the current behaviour when we
receive a T, D, D, ... message, libpq won't attempt to process data
until it receives whole data chunk. But with some modification on the
parser side, we can make it process data in such a way:
Recv: T
Proc: T
Recv: D
Proc: D
...
But in this case, some advanced function routines must be written to
access conn->result in a hardcoded way under strict control. Because,
PQgetReesult() won't work properly till it receives whole result set.
Furthermore, similar modifications on the PQgetResult() will cause
serious compatibility issues. Also, mentioned routines (to access
conn->result while receive-and-parse'ing at the same time) will make
it possible to receive partial results without using cursors.
Regards.
