Re: [HACKERS] jsonb - path

2015-06-10 Thread Andrew Dunstan
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscr

Re: [HACKERS] jsonb - path

2015-06-10 Thread Josh Berkus
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 th

Re: [HACKERS] jsonb - path

2015-06-10 Thread Tom Lane
Andrew Dunstan 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

Re: [HACKERS] jsonb - path

2015-06-10 Thread Petr Jelinek
On Wed, Jun 10, 2015 at 9:00 , Andrew Dunstan 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_p

[HACKERS] jsonb - path

2015-06-10 Thread Andrew Dunstan
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 th