On Tue, Jan 2, 2018 at 8:39 PM, Andrew Dunstan <andrew.duns...@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.steh...@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 >