Re: Tackling JsonPath support

From: Christian Convey <christian(dot)convey(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Tackling JsonPath support
Date: 2016-11-13 14:14:09
Message-ID: CAPfS4ZwaPMMLUQ6AFj=t182AAce-wGcDWzP9nHqkz3nx+H2_2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Pavel,

Can I check a few assumptions about what you're suggesting for this task?

* Our ultimate goal is to give Postgres an implementation of the functions
"JSON_EXISTS", "JSON_VALUE", and "JSON_QUERY" which fully comply with the
SQL standards.

* The best representation of those standards is found here: [1].

* When [1] mentions a "JSON path expression" or "JSON path language", it's
referring to the query language described here: [2].

* Even if other popular DBMS's deviate from [1], or other popular JSONPath
implementations deviate from [2], we remain committed to a faithful
implementation of [1].

* It's okay for my first commit to implement just two things: (a) a
PG-internal implementation of JsonPath, and (b) a user-visible
implementation of "JSON_QUERY" based on (a). Later commits could add
implementations of "JSON_VALUE", "JSON_EXISTS", etc. in terms of (a).

Thanks,
Christian

[1]
http://jtc1sc32.org/doc/N2501-2550/32N2528-WG3-Tutorial-Opening-Plenary.pdf

[2] http://goessner.net/articles/JsonPath

On Fri, Sep 16, 2016 at 2:28 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

> Hi
>
> 2016-09-15 18:05 GMT+02:00 Christian Convey <christian(dot)convey(at)gmail(dot)com>:
>
>> On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>> ...
>>
>> > I wrote XMLTABLE function, and I am thinking about JSON_TABLE function.
>> But
>> > there is one blocker - missing JsonPath support in our JSON
>> implementation.
>> >
>> > So one idea - implement JsonPath support and related JSON query
>> functions.
>> > This can help with better standard conformance.
>>
>> Hi Pavel,
>>
>> Are you still looking for someone to add the JsonPath support to the
>> JSON implementation? And if so, how urgently are people waiting for
>> it?
>>
>
> yes - JsonPath support should be great. I hope so this or next commitfest
> the XMLTABLE patch will be committed, and with JsonPath I can start to work
> on JSON_TABLE function.
>
> But the JsonPath can be merged separately without dependency to
> JSON_TABLE. There are more JSON searching functions, and these functions
> should to support JsonPath be ANSI SQL compliant.
>
>
>>
>> I'd be happy to start working on a patch, but since I'm new to PG
>> development, I'm probably not the fastest person to get it done.
>>
>
> It is not problem. Probably you should to do this work without deep
> knowledges about PostgreSQL internals. The work with data types (and
> functions for data types) is well isolated from PostgreSQL engine.
>
> You can learn from current searching on JSON -
> postgresql/src/backend/utils/adt/json.c
>
> And it is good start to be PostgreSQL's hacker - I started with
> implementation of own data type and related functions.
>
> Regards
>
> Pavel
>
>
>> Kind regards,
>> Christian
>>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2016-11-13 14:48:25 Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Previous Message Emre Hasegeli 2016-11-13 13:05:17 Re: Floating point comparison inconsistencies of the geometric types