Re: jsonb and nested hstore

On 2014-02-10 18:16:15 -0600, 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.

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