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(at)agliodbs(dot)com
> <mailto:josh(at)agliodbs(dot)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