Re: Column info without executing query

From: Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Jacob Coby <jcoby(at)listingbook(dot)com>, Dan Strömberg <dan(dot)stromberg(at)stockholm(dot)bonet(dot)se>, pgsql-general(at)postgresql(dot)org
Subject: Re: Column info without executing query
Date: 2006-07-21 14:07:08
Message-ID: 20060721140708.GE1351@alamut.tdm.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Csaba Nagy 2006-07-21 14:14:34 Re: Create index hanging
Previous Message Jacob Coby 2006-07-21 14:04:05 Re: Column info without executing query