> It's designed that way intentionally to aid in error detection. Parsing
> the packet following its internal structure should end up exactly at the
> end of the packet according to the length word. Otherwise something's
> corrupted.
Why you do not follow this rule for all messages?
70 00 00 00 27 6D 64 35 63 32 36 35 31 31 65 31 p...'md5c26511e1
31 39 65 39 33 62 30 32 35 32 64 32 39 31 38 31 19e93b0252d29181
64 34 38 61 64 37 66 62 d48ad7fb
53 00 00 00 1C 63 6C 69 65 6E 74 5F 65 6E 63 6F S... client_enco
64 69 6E 67 00 57 49 4E 31 32 35 31 00 ding.WIN1251.
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: <Eugen.Konkov@aldec.com>
Cc: "Alvaro Herrera" <alvherre@commandprompt.com>;
<pgsql-bugs@postgresql.org>
Sent: Wednesday, April 16, 2008 6:34 PM
Subject: Re: [BUGS] BUG: Protocol 3.0 ErrorResponse: Last 'null'
characterseems odd
> <Eugen.Konkov@aldec.com> writes:
>>> It's part of the protocol, actually (yes, two NUL bytes -- first one
>>> signals the end of the previous string, the second one signals the end
>>> of the packet).
>
>> The end of the packet can be obtained by packet length
>
> It's designed that way intentionally to aid in error detection. Parsing
> the packet following its internal structure should end up exactly at the
> end of the packet according to the length word. Otherwise something's
> corrupted.
>
> There are some backwards-compatibility considerations here too (the
> internal structure matches pre-V3 protocol which had no length word).
> But it's a perfectly fine definition and we have absolutely no intention
> of "fixing" it.
>
> regards, tom lane
