Re: [HACKERS] SQL/JSON in PostgreSQL - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] SQL/JSON in PostgreSQL
Date
Msg-id CAFj8pRCv2yUY3AHx5Tk_0VVcgTz2COF=eEd5Y=fRf4Avh=GAPw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SQL/JSON in PostgreSQL  (David Steele <david@pgmasters.net>)
List pgsql-hackers


2017-03-03 21:49 GMT+01:00 David Steele <david@pgmasters.net>:
Hi Oleg,

On 2/28/17 2:55 PM, Pavel Stehule wrote:
> 2017-02-28 20:08 GMT+01:00 Oleg Bartunov <obartunov@gmail.com
>
>     Attached patch is an implementation of SQL/JSON data model from
>     SQL-2016 standard (ISO/IEC 9075-2:2016(E)), which was published
>     2016-12-15 and is available only for purchase from ISO web site
>     (https://www.iso.org/standard/63556.html
>     <https://www.iso.org/standard/63556.html>). Unfortunately I didn't
>     find any public sources of the standard or any preview documents,
>     but Oracle implementation of json support in 12c release 2 is very
>     close
>     (http://docs.oracle.com/database/122/ADJSN/json-in-oracle-database.htm
>     <http://docs.oracle.com/database/122/ADJSN/json-in-oracle-database.htm>),
>     also we used https://livesql.oracle.com/  to understand some details.

<...>

> This is last commitfest for current release cycle - are you sure, so is
> good idea to push all mentioned features?

Implementing standards is always a goal of the PostgreSQL community, but
this is a very large patch arriving very late in the release cycle with
no prior discussion.

That the patch proposed follows a standard which will not be available
to the majority of reviewers is very worrisome, let alone the sheer
size.  While much of the code is new, I see many changes to core data
structures that could very easily be destabilizing.

I propose we move this patch to the 2017-07 CF so further development
and review can be done without haste and as the standard becomes more
accessible.

Although I would to see these features in Postgres early I have same feeling. Is it a question if some features can be implemented easy and can be merged early? 

The implementation of some JSON generation functions can be easy and the verification should not be hard. Different situation is in JSON querying functions.  Merging JSONPath in first commitfest is better.

Regards

Pavel


Regards,
--
-David
david@pgmasters.net

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] patch: function xmltable
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] GUC for cleanup indexes threshold.