On 2014-02-10 18:16:15 -0600, Merlin Moncure wrote: > On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > It works in enough cases atm that it's worthwile trying to keep it > > working. Sure, it could be better, but it's what we have right now. Atm > > it's e.g. the only realistic way to copy larger amounts of bytea between > > servers without copying the entire cluster. > > That's the thing -- it might work today, but what about tomorrow? > We'd be sending the wrong signals. People start building processes > around all of this and now we've painted ourselves into a box.
That ship has sailed. > Better in my mind to simply educate users that this practice is dangerous and > unsupported, as we used to do. But we don't have any alternatives for such scenarios, so that just amounts to "screw you". If there are good reason for just breaking binary protocol compatibility, I can live with that, but that's really not the case here. The additional amount of code is *miniscule*, even after adding a real binary protocol format since all the code has to be there for the plain send/recv functions anyway. The amount of interesting and acceptable binary protocol changes has gotten lower in step with the acceptance of on-disk compatibility changes, which isn't particularly surprising. > I guess until now. It seems completely > odd to me that we're attaching a case to the jsonb type, in the wrong > way -- something that we've never attached to any other type before. > For example, why didn't we attach a version code to the json type send > function? Wasn't the whole point of this is that jsonb send/recv be > more spiritually closer to json? If we want to introduce alternative > type formats in the 9.5 cycle, why can't we attach version based > encoding handling to *that* problem? That doesn't make any sense to me. jsonb is a separate type because it behaves differently than json. So I don't see how that plays a role here. And if we add a new format version in 9.5 we need to make it discernible from the 9.4 format. Without space for a format indicator we'd have to resort to ugly tricks like defining the high bit in the first byte set indicates the new version. I don't see the improvement here. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
