On Wed, Jun 10, 2015 at 9:00 , Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers