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. Better in my mind to simply educate users that this practice is dangerous and unsupported, as we used to do. 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? The more angles I look at this from the more it looks messy and rushed. Notwithstanding all the above, I figure here enough smart people disagree (once again, heh) to call it consensus. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
