From: Oleg Bartunov <obartunov(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Piotr Stefaniak <email(at)piotr-stefaniak(dot)me>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL
Date: 2018-01-02 21:38:11
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Jan 2, 2018 at 8:39 PM, Andrew Dunstan
<andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> On 01/02/2018 02:44 PM, Oleg Bartunov wrote:
>> On Tue, Jan 2, 2018 at 10:47 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.


> 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
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-02 21:49:28 Re: Copyright update
Previous Message Bruce Momjian 2018-01-02 21:33:22 Copyright update