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

On 01/02/2018 03:48 PM, Pavel Stehule wrote:
>
>
> 2018-01-02 21:39 GMT+01:00 Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com <mailto:andrew.dunstan@2ndquadrant.com>>:
>
>
>
>     On 01/02/2018 02:44 PM, Oleg Bartunov wrote:
>     > On Tue, Jan 2, 2018 at 10:47 AM, Pavel Stehule
>     <pavel.stehule@gmail.com <mailto:pavel.stehule@gmail.com>> wrote:
>
>     >> I am looking on this patch set and it looks very well.
>     >>
>     >> Personally I dislike any extensions against SQL/JSON in this
>     patch. And
>     >> there is lot of extensions there. It doesn't mean so these
>     extensions are
>     >> bad, but it should be passed as next step and there should be
>     separate
>     >> discussion related to these extensions.
>     >>
>     >> Please, can you reduce this patch to only SQL/JSON part?
>     > +1, our goal is to push the standard to PG 11, which is more or
>     less realistic.
>     > Nikita will rearrange the patch set, so patches 1, 2, 4, 7, 8,
>     9, 10,
>     > 11, 12, which
>     > implement SQL/JSON could be applied without extra patches.
>     >
>     > Patches 5,6 are desirable, since we can implement custom
>     operators. This is
>     > very important for postgres, which is known as extensible
>     database with rich set
>     > of extensions. Think about geojson with spatial operators or  array
>     > operators, for
>     > example. But I agree, it's subject of separate thread.
>     >
>     > In very extreme case, we could commit for PG 11 only
>     jsonpath-related patches
>     > 1,2 and probably 4.  I think, that jsonpath is what we really
>     miss in postgres.
>
>
>     That seems a bit pessimistic. I hope we can do lots better.
>
>     It looks to me like patches 1, 7 and 8 can stand alone, and should be
>     submitted separately, and we should try to get them committed early.
>     These are all small patches - a couple of hundred lines each.
>
>     Patches 2, 3, and 4 should come next - I included patch 3 because I
>     think GIN indexing is going to be critical to success.
>
>     After that 9, 10, 11 and 12.
>
>     I don't have a problem with the rest, but they should probably have a
>     lower priority. If we can get to them well and good.
>
>     We should stop use the word 'extension' when we don't mean what
>     Postgres
>     calls an extension (which is only patch 14 in this case). Call it an
>     addition or extra feature or something else. Otherwise it gets
>     confusing.
>
>     I'm not 100% clear on why we're adding jsonpathx as an extension,
>     though. Do we not think most json users will want to use map,
>     reduce etc.?
>
>
> In this moment, there is lot of code, and we should be concentrated to
> merging the core of this feature. I am sure, so discussion about extra
> features will come, and will be more realistic and less nervous if
> SQL/JSON will be merged already.
>
> I looked to patch - and It is big, really big - we should to start
> with some important subset that we can understand and test well.


Sure, I agree, we should start with jsonpath, and then move on to 
SQL/JSON and then the json_table patches. Patches 5, 6, 13 and 14 would
come last. That's the order I suggested above. My question was whether
or not, when we finally get to jsonpathx we really want to make it an
extension. I can't see a very good reason for doing so.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services