Re: jsonb - path

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