From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Further issues with jsonb semantics, documentation |
Date: | 2015-06-04 17:26:00 |
Message-ID: | 55708A28.2040105@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/04/2015 11:33 AM, Jim Nasby wrote:
> On 6/4/15 8:43 AM, Andrew Dunstan wrote:
>> You are conflating two different things here, quite pointlessly. The RH
>> operand of ?| is not a path, whereas the RH operand of this - variant
>> is. The fact that they are both text arrays doesn't mean that they
>> should mean the same thing. And this is really the whole problem with
>> the rest of your analysis.
>
> Has the idea of a specific json_path datatype been discussed? I feel
> it would add a lot of clarity to the operators. It would also make it
> easy to have an array of paths, something that's difficult to do today
> because a path can be an arbitrary length and arrays don't support that.
I actually thought of doing something like that earlier today, although
I was thinking of making it an array under the hood - I'm not sure how
much call there is for an array of paths. We could probably finesse
that. I agree that there is some sense in having such a type, especially
if we later want to implement json(b)_patch, see
<http://tools.ietf.org/html/rfc6902>. And if we do we should call the
type json_pointer to be consistent with
<http://tools.ietf.org/html/rfc6901>.
However, this is certainly not 9.5 material.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-04 17:26:26 | Re: brin regression test intermittent failures |
Previous Message | Alvaro Herrera | 2015-06-04 17:24:51 | Re: brin regression test intermittent failures |