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

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.

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.?

cheers

andrew

--
Andrew Dunstan                https://www.2ndQuadrant.com

PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services