On 01/02/2018 03:48 PM, Pavel Stehule wrote: > > > 2018-01-02 21:39 GMT+01:00 Andrew Dunstan > <andrew.duns...@2ndquadrant.com <mailto:andrew.duns...@2ndquadrant.com>>: > > > > 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 <mailto: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. > > 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
