Re: Tackling JsonPath support

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Christian Convey <christian(dot)convey(at)gmail(dot)com>
Cc: Nico Williams <nico(at)cryptonector(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Tackling JsonPath support
Date: 2016-11-29 16:18:17
Message-ID: 80228378-f5ba-1291-872b-9812e103e37c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/11/16 07:37, Pavel Stehule wrote:
>
>
> 2016-11-29 7:34 GMT+01:00 Christian Convey <christian(dot)convey(at)gmail(dot)com
> <mailto:christian(dot)convey(at)gmail(dot)com>>:
>
> On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule
> <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>>wrote:
>
> We now support XPath function - JSONPath is similar to XPath -
> it is better for user, because have to learn only one language.
>
>
> I'm not sure I understand.
>
> Are you suggesting that we use XPath, not JSONPath, as our language
> for json-path expressions?
>
>
> surely not.
>
> follow ANSI/SQL :)
>

Just to add to this, the SQL/JSON proposals I've seen so far, and what
Oracle, MSSQL and Teradata chose to implement already is basically
subset of jsonpath (some proposals/implementations also include
lax/strict prefix keyword on top of that). I think that should give us
some hint on what the base functionality should look like.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2016-11-29 16:28:38 Re: Tackling JsonPath support
Previous Message Christian Convey 2016-11-29 16:16:29 Re: Tackling JsonPath support