Re: Tackling JsonPath support

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Tackling JsonPath support
Дата
Msg-id CAFj8pRBUrXjZz+jd1AEEbCS+SODmrtr4zW=a0yFDFNfe6xNxWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tackling JsonPath support  (Christian Convey <christian.convey@gmail.com>)
Список pgsql-hackers
Hi

2016-11-13 15:14 GMT+01:00 Christian Convey <christian.convey@gmail.com>:
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).

My goal is implementation of JSON_TABLE function - this function can be used instead any other mentioned function (and it is really useful - it is usual task - transform JSON to table). The SQL/JSON is pretty new and bigger for implementation in one step. Nobody knows it from PostgreSQL world. The our SQL/XML needed more than 10 years and still is not fully complete - and we used power and features libxml2 (nothing similar we have for JSON). But almost what is daily need from SQL/XML we have. For JSON_TABLE we need only basic features of JSONPath - the predicates are not necessary in first step.

http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/json/src/tpc/db2z_bif_jsontable.html The vendors use name for this query language "SQL/JSON path expressions" - so important source is SQL/JSON (this can be different than origin JSONPath (your second source)).

Regards

Pavel




Regards

Pavel


On Fri, Sep 16, 2016 at 2:28 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

2016-09-15 18:05 GMT+02:00 Christian Convey <christian.convey@gmail.com>:
On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule <pavel.stehule@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: psql \setfileref
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Physical append-only tables