Re: libpq Describe Extension [WAS: Bytea and perl] - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: libpq Describe Extension [WAS: Bytea and perl]
Date
Msg-id 20060626124304.GC24611@svana.org
Whole thread Raw
In response to Re: libpq Describe Extension [WAS: Bytea and perl]  (Volkan YAZICI <yazicivo@ttnet.net.tr>)
List pgsql-hackers
On Sat, Jun 24, 2006 at 02:45:33PM +0300, Volkan YAZICI wrote:
> I totally agree with the followed ugly style. But IMHO the recursive
> parsing (that is followed in pqParseInputN()) of received data is the main
> problem behind this. I think, it will even get harder everytime somebody
> try to to add another type of message parsing capability to that loop.
> For instance, isn't pollution of PGQueryClass with state variables (like
> PGQUERY_PREPARE or PGQUERY_DESCRIBE) one of the proofs of this.

What's the alternative? pqParseInputN() work using state machines, but
they're not recursive. You're trying to parse messages where you don't
know beforehand if you have enough data. Moreover, each message could
be quite large, you don't want to have to store all of them without
parsing what you can. You're also not allowed to wait for more data to
appear.

However, it seems to me you could simplify quite a bit of coding by
adding a pqHaveNBytes function that returns true if there are that many
bytes available. Then right after you know the number of attributes,
you can do a pqHaveNBytes(4*nattr) and skip the checking within the
loop.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: vacuum, performance, and MVCC
Next
From: Bruce Momjian
Date:
Subject: Re: vacuum, performance, and MVCC