Re: Column info without executing query

Поиск
Список
Период
Сортировка
От Volkan YAZICI
Тема Re: Column info without executing query
Дата
Msg-id 20060721144731.GF1351@alamut.tdm.local
обсуждение исходный текст
Ответ на Re: Column info without executing query  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Column info without executing query  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
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.

В списке pgsql-general по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: Column info without executing query
Следующее
От: Erik Jones
Дата:
Сообщение: Impact of vacuum full...