Re: [HACKERS] SQL/JSON in PostgreSQL - Mailing list pgsql-hackers
From | Nikita Glukhov |
---|---|
Subject | Re: [HACKERS] SQL/JSON in PostgreSQL |
Date | |
Msg-id | 2778884b-2293-4982-4cf9-76bc31969edb@postgrespro.ru Whole thread Raw |
In response to | Re: [HACKERS] SQL/JSON in PostgreSQL (Oleg Bartunov <obartunov@gmail.com>) |
Responses |
Re: [HACKERS] SQL/JSON in PostgreSQL
Re: [HACKERS] SQL/JSON in PostgreSQL Re: [HACKERS] SQL/JSON in PostgreSQL |
List | pgsql-hackers |
On 03.01.2018 00:38, Oleg Bartunov wrote: > On Tue, Jan 2, 2018 at 8:39 PM, Andrew Dunstan > <andrew.dunstan@2ndquadrant.com> wrote: >> >> 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> 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. > Would love too ! > >> 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. > +1 > >> Patches 2, 3, and 4 should come next - I included patch 3 because I >> think GIN indexing is going to be critical to success. > agree, we can consider patch 4 later > >> After that 9, 10, 11 and 12. > > again, 10 , 12 may be considered later > >> 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. > +1, lets call 'extra' > >> 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.? > We decided to do that, since the whole patch set is already big. > >> >> >> cheers >> >> andrew >> >> -- >> Andrew Dunstan https://www.2ndQuadrant.com >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> I have removed all extra features from the patch set, they can be found in our github repository: https://github.com/postgrespro/sqljson/tree/sqljson_ext. Now there are 10 patches which have the following dependencies: 1: 2: 1 3: 2 4: 2 5: 6: 7: 2, 5, 6 8: 7, 4 9: 7 10: 8, 9 -- Nikita Glukhov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
pgsql-hackers by date: