Merlin Moncure <mmonc...@gmail.com> writes: > On Tue, Nov 22, 2011 at 6:52 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers