Re: Tackling JsonPath support - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Tackling JsonPath support
Date
Msg-id a097265c-a701-4099-6bd4-1e2c0a1340d3@2ndquadrant.com
Whole thread Raw
In response to Re: Tackling JsonPath support  (Christian Convey <christian.convey@gmail.com>)
List pgsql-hackers

On 28/11/16 18:57, Christian Convey wrote:
> 
> On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule <pavel.stehule@gmail.com
> <mailto:pavel.stehule@gmail.com>> wrote
> 
>     > I thought by adding my first implementation to "contrib", we could make this functionality available to
end-users,even before there was a consensus about what PG's "official" JSON-related operators should have for syntax
andsemantics.
 
>     >
> 
>     this time the commiters dislike the contrib dir. It is hard to push
>     there anything :-(. You can try it, but it can be lost time.
> 
> 
> ​Thanks for the warning.  I'm okay with  my patch adding the "json_path"
> function to the core PG code.​
> 
> I would still suggest that we hold off on having my first patch
> implement an official JSON-related operator such as "JSON_TABLE".  I
> would prefer to have my "json_path" function available to users even
> before we know how "JSON_TABLE", etc. should behave.
> 
> ​Does that sound reasonable?​
> 

Hi,

just make it extension, not contrib module, there is not much difference
between those except contrib is included in distribution.

Extensions that provide just functions are easy to integrate into core
(that's how some of the existing json functions were added in the past
as well).

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: PSQL commands: \quit_if, \quit_unless
Next
From: Andrew Dunstan
Date:
Subject: Re: PSQL commands: \quit_if, \quit_unless