Re: jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 8:41 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Is there a particular reason why "+" makes more sense as "shallow
> concatination" and "||" makes more sense as "deep concatination"? Like,
> something in JS or other client languages which would make that
> preference make more sense to users?
>
> While I hate last-minute changes in general, once we have this
> functionality as || we won't be able to swap operators later if we
> decide that deep concatination should have been ||. So I want to be
> clear on why users will prefer that to + .

This guy is talking about the concatenation operator in hstore:
https://twitter.com/toolmantim/status/589348855302344705

I don't want to present this operator as being the equivalent for
jsonb (the thing you use for assignment). I wish it was, but it just
isn't, as long as it treats the first nesting level as special. jsonb
is all about nesting in general, and its concatenate operator must
reflect this. It wouldn't be much use if "operator @> jsonb" didn't
care about nesting either, but it does (unlike hstore's equivalent,
because hstore doesn't nest).

I don't think that (say) an "operator + jsonb" ought to be called a
concatenation operator at all. The idea is to distance what we have
here from the idea of an hstore concatenate operator, and to encourage
the understanding that it has only a specialized use. I think that the
danger of someone making the wrong assumption about the new "operator
|| jsonb" is very real (I think that the reverse wouldn't be true,
though, if concatenation worked in a nested fashion -- that wouldn't
bother users that had non-nested jsonb documents).

As I said, I don't think that my preference for deep concatenation is
a matter of taste. I think that shallow concatenation is fundamentally
and objectively at odds with what jsonb is supposed to be (as long as
concatenation is the way "nested assignment" works, which is what
users have been taught to think).
--
Peter Geoghegan