On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund <andres@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
