Re: Further issues with jsonb semantics, documentation

On 06/05/2015 02:32 PM, Alvaro Herrera wrote:
>> 'some jsonb value' - '{foo,bar}' is already ambiguous  - the RH operand
>> could be a single text datum or a text array.
> Hmm, but that's not in 9.4, so we can still tweak it if necessary.
>
> Consider this jsonb datum.  Nobody in their right mind would have a key
> that looks like a path, I hear you say; yet I'm sure this is going to
> happen.
>
> alvherre=# select jsonb '{"a":"1", "b":"2", "c": {"a": "2"}, "{c,a}": "uh"}' ;
>                          jsonb
> ------------------------------------------------------
>   {"a": "1", "b": "2", "c": {"a": "2"}, "{c,a}": "uh"}
> (1 fila)
>
> This seems pretty surprising to me:
>
> -- here, the -(jsonb,text) operator is silently chosen, even though the
> -- right operand looks like an array.  And we do the wrong thing.
> alvherre=# select jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' -  '{c,a}';
>                 ?column?
> ---------------------------------------
>   {"a": "1", "b": "2", "c": {"a": "2"}}
> (1 fila)
>
> -- here, the -(jsonb,text[]) operator is chosen
> alvherre=# select jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' -  _text '{c,a}';
>             ?column?
> -------------------------------
>   {"a": "1", "b": "2", "c": {}}
> (1 fila)
>
> But this seems worse to me, because we silently do nothing:
>
> alvherre=# select jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' -  '{c,a}';
>                 ?column?
> ---------------------------------------
>   {"a": "1", "b": "2", "c": {"a": "2"}}
> (1 fila)
>
>
> I think the first operator can be qualified as dangerous.  If you delete
> that one, then it's fine because you can't do that query anymore because
> of the conflict with -(jsonb, int).
>
> alvherre=# select jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' -  '{c,a}';
> ERROR:  operator is not unique: jsonb - unknown
> LÍNEA 1: ...elect jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' -  '{c,a}'...
>                                                                ^
> SUGERENCIA:  Could not choose a best candidate operator. You might need to add explicit type casts.



Yeah, Good point. Actually, if my memory serves me correctly (always a
dubious bet), the avoidance of that kind of ambiguity is why we
introduced the #> and #>> operators in the first place, after going
round and round for a while on what the API would look like. I should
have remembered that when this came around. Mea culpa.

So probably the least invasive change would be to rename the text[]
variant operator to something like "#-" and rename the corresponding
function to jsonb_delete_path.

We could also decide not to keep an operator at all, on the ground that
we think we'll implement a type that encapsulates json pointer in 9.6,
and just keep the renamed function.

cheers

andrew