Re: libpq Describe Extension [WAS: Bytea and perl]

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: libpq Describe Extension [WAS: Bytea and perl]
Дата
Msg-id 20060626124304.GC24611@svana.org
обсуждение исходный текст
Ответ на Re: libpq Describe Extension [WAS: Bytea and perl]  (Volkan YAZICI <yazicivo@ttnet.net.tr>)
Список 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 по дате отправления:

Предыдущее
От: "Zeugswetter Andreas DCP SD"
Дата:
Сообщение: Re: vacuum, performance, and MVCC
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: vacuum, performance, and MVCC