Re: jsonb concatenate operator's semantics seem questionable

On 05/18/2015 04:54 PM, David G. Johnston wrote:
> On Mon, May 18, 2015 at 12:12 PM, Josh Berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>>wrote:
>
>     On 05/18/2015 11:58 AM, Peter Geoghegan wrote:
>     > As you say, hstore isn't nested, and so this simply doesn't come up
>     > there. We have failed to adopt "||" to jsonb in a way that makes
>     > sense. We should have adopted it to jsonb in exactly the same way as
>     > the "@>" operator was.
>
>     The only question worth discussing is whether we change the
>     operator to
>     "+" (or, for that matter, something else).  I've seen your vote on
>     this,
>     so, does anyone else have an opinion on "+" vs. "||"? Preferably
>     with a
>     justification with some kind of grounding?
>
>
> How about a pair of operators?
>
> ​jsonb |> jsonb​ "push these keys into that jsonb, replacing existing
> values for any keys already present"
> ​jsonb <| jsonb​ "pull those keys into this jsonb, [...]"
>
> I do suspect, however, that any kind of deep concatenation/replacement
> algorithm is going to require end-user input and thus will want to be
> done strictly through functions as opposed to operators.
>
> Given the complexity of json I'm not convinced that either + or ||
> should end up being implemented.  Those are operators best left to
> simple types where the meaning of "add" and "concatenate" are well
> defined.  Even if we do end up with the deep "concatenation"
> algorithm, and decide to turn it into an operator, at this moment I
> would not choose || to be that operator.
>
> This entire thread is the justification for the last
> paragraph...unfortunately the rest is just my opinion.
>
>

I agree that we might need more than one merge operator, or possibly
none and a merge function with options. But I haven't yet seen an
argument that convinces me we need to rename the operation we do have.

cheers

andrew