From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | 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 05:28:17 |
Message-ID: | CAFj8pRAtvZAtA2OBiyZyjf+AC24g6oSuKsbA8uWGZFZOoq=hDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-11-29 2:50 GMT+01:00 Christian Convey <christian(dot)convey(at)gmail(dot)com>:
> On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams <nico(at)cryptonector(dot)com>
> wrote:
> ...
>
>> JSON Path is not expressive enough (last I looked) and can be mapped
>> onto jq if need be anyways.
>>
>
> Hi Nico,
>
> Could you please clarify what you mean by "not expressive enough"?
>
> I ask because I've been struggling to identify clear requirements for the
> json-path functionality I'm trying to provide. It sounds like perhaps you
> have something concrete in mind.
>
> Since I myself have no need currently for this functionality, I'm left
> guessing about hypothetical users of it. My current mental model is:
>
> (a) Backend web developers. AFAICT, their community has mostly settled on
> the syntax/semantics proposed by Stefan Groessner. It would probably be
> unkind for PG's implementation to deviate from that without a good reason.
>
> (b) PG hackers who will eventually implement the ISO SQL standard
> operators. In the standards-committee meeting notes I've seen, it seemed
> to me that they were planning to define some operators in terms of
> json-path expression. So it would probably be good if whatever json-path
> function I implement turns out to comply with that standard, so that the
> PG-hackers can use it as a building block for their work.
>
> (c) Pavel. (I'm still somewhat unclear on what has him interested in
> this, and what his specific constraints are.)
>
My target is simple - 1. to have good ANSI/SQL support, 2. to have good
JSON to relation mapping function - ANSI/SQL JSONTABLE does it.
We now support XPath function - JSONPath is similar to XPath - it is better
for user, because have to learn only one language.
Regards
Pavel
>
> - Christian
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bandy | 2016-11-29 05:31:51 | Re: GiST support for UUIDs |
Previous Message | Mithun Cy | 2016-11-29 05:26:50 | Re: Proposal : For Auto-Prewarm. |