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
