Thread: jsonb - path

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

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

Andrew Dunstan <andrew@dunslane.net> writes:
> 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,

Implicit cross-type-category casts are almost always a bad idea.
Usually you don't find out how bad until after you've shipped it.

It's possible this would be okay, given the probable limited usage
of json_pointer.  But I think it's darn risky to make decisions now
that are contingent on the assumption that such a cast won't have
untenable side-effects.

In particular, such a cast would create substantial hazards for any
operator that's named similarly to one of the json(b) operators and could
take a text array on the right.  While there don't seem to be any of those
at the moment (at least not in core), this is certainly another good
reason not to use "-" as the jsonb_delete operator.
        regards, tom lane

On 06/10/2015 12:00 PM, Andrew Dunstan wrote:
> 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.

Speaking as a user ... works for me.

> We need to rename the corresponding operator from'-' to, say, '-#', or
> alternatively remove it. The question is which.

Rename, I think.

> 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.

WFM.  So the idea is that if json_pointer is implemented as a type, then
we'll have an operator for "jsonb - json_pointer"?


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 06/10/2015 06:08 PM, Josh Berkus wrote:
> WFM.  So the idea is that if json_pointer is implemented as a type, then
> we'll have an operator for "jsonb - json_pointer"?
>
>

Right.

cheers

andrew