Merlin Moncure <mmoncure@gmail.com> writes:
> On Tue, Nov 22, 2011 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The only way that anything like this will go in is as part of a protocol
>> version bump,
> Wire format changes can only be made with a protocol version bump? Is
> this a new policy? In the past they were just made...for example the
> money type was bumped to 64 bits. In the past it was always buyer
> beware for binary format consumers.
Well, (a) our standards have gone up over time, (b) binary protocol is
getting more widely used (in part due to your own efforts), and (c)
money is a third-class stepchild anyway. I don't think we can get away
with changing the binary representation of such widely used types as
int and float arrays, unless we have some pretty carefully thought
through notion of how the client and server will negotiate what to do.
Now it's possible we could do that without formally calling it a
protocol version change, but I don't care at all for the idea of coming
up with one-off hacks every time somebody decides that some feature is
important enough that they have to have it Right Now instead of waiting
for a sufficient accumulation of reasons to have a protocol flag day.
I think "but we made arrays a bit smaller!" is a pretty lame response
to have to give when somebody complains that Postgres 9.2 broke their
client software. When we do it, I want to have a *long* list of good
reasons.
BTW, so far as the actual array format is concerned, I don't think
the proposal is acceptable as-is: it renders the received array entirely
unreadable unless the reader knows a-priori what the sender thought the
typlen was. It would be a lot better if the fixed-length flag meant
that the typlen is given once in the array header rather than once per
element. I'm not thrilled by the "no nulls" restriction, either,
though I admit I don't have a good idea about avoiding that offhand.
regards, tom lane