Re: Column info without executing query

On Jul 21 04:25, Martijn van Oosterhout wrote:
> On Fri, Jul 21, 2006 at 05:07:08PM +0300, Volkan YAZICI wrote:
> > 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:
>
> Actually, you're wrong. It processes the T as it comes in, and then
> each D as it comes in. "message body" in this case refers to a single
> 'T' or 'D' record, not the entire query result.

That's what I was suspicious at the beginning, whether "message body"
refers to a single record or an entire query. But I forget to check
while typing. :)

> > 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.
>
> Did you see my comment about get partial result sets from libpq. for
> asyncronous queries you can run PQftype as soon as you've received and
> parsed the T record

We can run PQftype() on what, conn->result? (We can't use a PGresult
will be returned from a PQgetResult() in here; because, AFAIK, after
a getRowDescriptions(), PQgetResult() still won't return a PGresult
because of conn->asyncStatus is still PGASYNC_BUSY.) That's why I
proposed generic methods to give user the conn->result access under
control.

Also, how can a client can realize whether T message is parsed
completely?

Regards.