On Wed, Jun 10, 2015 at 9:00 , Andrew Dunstan <andrew@dunslane.net>
wrote:
> 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.
Hmm, so our implementation of json pointer would be slightly
non-standard as it would support alternative input syntax. This does
not make me thrilled but since we can't really make it work any other
way, I guess it's pragmatic solution...
> 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.
+1 for renaming
-- Petr Jelinek http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
