This is an attempt to summarize What I think is now the lone outstanding
jsonb issue.
We need to remove the ambiguity with jsonb_delete() by renaming the
variant that takes a text[] (meaning a path) as the second argument to
jsonb_delete_path. That seems uncontroversial.
We need to rename the corresponding operator from'-' to, say, '-#', or
alternatively remove it. The question is which.
Future plans that might affect this issue: possible implementations of
Json Pointer (rfc 6901), Json Patch (rfc 6902) and Json Merge Patch (rfc
7396). The last one is on this list for completeness - it seems to me a
lot less useful than the others, but I included it because Peter felt
strongly about the lack of recursive merge. Json Patch could probably
stand on its owm once we have Json Pointer, so that's really the thing
we need to talk about. Undeneath the hood, I think we could make
json_pointer be simply an array of text. If we did that, we could make
an implicit cast from text[] to it, and we could also have the input
routine recognize an input string beginning with '{' and parse it
directly as an array of text, since a standard json pointer expression
has to being with '/' unless it's completely empty. Given all of that, I
think, fingers crossed, it should be fairly safe to change the signature
of all the functions and operators that currently take text[] as their
path parameter to take a json_pointer instead without causing too much
grief.
Proceeding from that, I'm rather inclined to say that the answer is to
rename the operator rather than remove it, and that's what I'm going to
do unless there's a groundswell that says no.
We should also in 9.6 provide an operator or function that removes all
the named top-level keys. That operator's function would not be a json
pointer, but an array of key names.
cheers
andrew
