Re: jsonb and nested hstore

On Tue, Feb 11, 2014 at 3:35 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> On 02/11/2014 01:16 AM, Merlin Moncure wrote:
>> On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund <andres(at)2ndquadrant(dot)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?
> JSON is supposed to be a *standard* way of encoding data in
> strings. If the ever changes, it will not be JSON type anymore.

My point was that as we reserved the right to change jsonb binary
format we'd probably want to reserve the right to change json's as
well. This was in support of the theme of 'why is jsonb a special
case?'. However, I think it's pretty much settled that the any
potential concerns I raised in terms of providing a version flag are
outweighed by it's potential usefulness.

merlin