Re: [HACKERS] Tackling JsonPath support

On 11/28/16 12:38 PM, Nico Williams wrote: The internal representation of JSON data is bound to be completely different, no doubt Actually, that could be a good thing. The internal storage of JSONB is optimized for compress-ability, but that imposes a substantial overhead to calls that are

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 05, 2016 at 11:52:57AM -0500, Tom Lane wrote: > Another point here is that packagers such as Red Hat strenuously dislike > such source-code-level wrapping of other projects, because that means that > they have to rebuild multiple packages to fix any bugs found in the > wrapped code.

Re: [HACKERS] Tackling JsonPath support

Robert Haas writes: > On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams wrote: >> What we do in Heimdal, OpenAFS, and other open source projects, some >> times, is include a copy / git submodule / similar of some such external >> dependencies. Naturally

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 5, 2016 at 11:42 AM, Nico Williams wrote: >> Library integrations are tricky but, since you wrote JQ and seem > > Just to be clear, Stephen Dolan wrote jq. I've added to, and maintained > jq, to be sure, but I would not want to take credit from Stephen. Ah,

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 05, 2016 at 11:28:31AM -0500, Robert Haas wrote: > The overall need is that it needs to be possible for PostgreSQL to > throw an ERROR, and thus longjmp, without leaking resources. As long as one can interpose jump buffers, that should be possible. > Sometimes those errors happen

Re: [HACKERS] Tackling JsonPath support

On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams wrote: > On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote: >> On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey >> wrote: >> > I think I can satisfy (3) with a PG extension which provides

Re: [HACKERS] Tackling JsonPath support

On Fri, Dec 2, 2016 at 1:32 PM, Nico Williams wrote: ... On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote: > > On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey > > wrote: > > > I think I can satisfy (3) with a PG extension which

Re: [HACKERS] Tackling JsonPath support

On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote: > On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey > wrote: > > I think I can satisfy (3) with a PG extension which provides a function that > > approximately implements JSONPath. My short-term plans are

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey wrote: > I think I can satisfy (3) with a PG extension which provides a function that > approximately implements JSONPath. My short-term plans are to submit such a > patch. FWIW, I think that's a fine plan. I don't

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 8:18 AM, Petr Jelinek wrote: ... > Just to add to this, the SQL/JSON proposals I've seen so far, and what > Oracle, MSSQL and Teradata chose to implement already is basically > subset of jsonpath (some proposals/implementations also include >

Re: [HACKERS] Tackling JsonPath support

On 29/11/16 17:28, Nico Williams wrote: > On Tue, Nov 29, 2016 at 05:18:17PM +0100, Petr Jelinek wrote: >> Just to add to this, the SQL/JSON proposals I've seen so far, and what >> Oracle, MSSQL and Teradata chose to implement already is basically >> subset of jsonpath (some

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 05:18:17PM +0100, Petr Jelinek wrote: > Just to add to this, the SQL/JSON proposals I've seen so far, and what > Oracle, MSSQL and Teradata chose to implement already is basically > subset of jsonpath (some proposals/implementations also include > lax/strict prefix keyword

Re: [HACKERS] Tackling JsonPath support

On 29/11/16 07:37, Pavel Stehule wrote: > > > 2016-11-29 7:34 GMT+01:00 Christian Convey >: > > On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule > >wrote: > >

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 10:37 PM, Pavel Stehule wrote: > > > 2016-11-29 7:34 GMT+01:00 Christian Convey : > >> On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule >> wrote: >> >>> ​​ >>> We now support XPath function -

Re: [HACKERS] Tackling JsonPath support

2016-11-29 7:34 GMT+01:00 Christian Convey : > On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule > wrote: > >> We now support XPath function - JSONPath is similar to XPath - it is >> better for user, because have to learn only one language. >> >

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule wrote: > We now support XPath function - JSONPath is similar to XPath - it is > better for user, because have to learn only one language. > I'm not sure I understand. Are you suggesting that we use XPath, not JSONPath, as

Re: [HACKERS] Tackling JsonPath support

2016-11-29 4:00 GMT+01:00 David G. Johnston : > On Mon, Nov 28, 2016 at 7:38 PM, Christian Convey < > christian.con...@gmail.com> wrote: > >> On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams >> wrote: >> >>> While XPath is expressive and compact,

Re: [HACKERS] Tackling JsonPath support

2016-11-29 2:50 GMT+01:00 Christian Convey : > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > wrote: > ... > >> JSON Path is not expressive enough (last I looked) and can be mapped >> onto jq if need be anyways. >> > > ​Hi Nico, > > Could you

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 08:00:46PM -0700, David G. Johnston wrote: > IMO jq is considerably closer to XSLT than XPath - which leads me to figure > that since xml has both that JSON can benefit from jq and json-path. I'm > not inclined to dig too deep here but I'd rather take jq in the form of >

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 7:38 PM, Christian Convey < christian.con...@gmail.com> wrote: > On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams > wrote: > >> While XPath is expressive and compact, XSLT >> is rather verbose; jq is as expressive as XSLT, but with the compact >>

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 06:38:55PM -0800, Christian Convey wrote: > On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams > wrote: > > > > Thanks for the explanation. It sounds like your original point was NOT > that json-path isn't sufficient for "${specific use X}". The only

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams wrote: > On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > > wrote: > > ... > > > JSON Path is not expressive enough (last I looked)

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams > wrote: > ... > > JSON Path is not expressive enough (last I looked) and can be mapped > > onto jq if need be anyways. > > Hi Nico, > > Could you please

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams wrote: ... > JSON Path is not expressive enough (last I looked) and can be mapped > onto jq if need be anyways. > ​Hi Nico, Could you please clarify what you mean by "not expressive enough"? I ask because I've been

Re: [HACKERS] Tackling JsonPath support

On 28/11/16 18:57, Christian Convey wrote: > > On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule > wrote > > > I thought by adding my first implementation to "contrib", we could make > this functionality available to end-users, even

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 05:56:41PM +0100, Pavel Stehule wrote: > Dne 28. 11. 2016 17:26 napsal uživatel "David Fetter" : > > There's another option we should also consider: jq > > . It's available under a > > PostgreSQL-compatible license, and has

Re: [HACKERS] Tackling JsonPath support

I wonder what it might take to integrate jq[1] (via libjq) with PostgreSQL... The internal representation of JSON data is bound to be completely different, no doubt, but jq is a fantastic language, akin to XPath and XSLT combined, but with nice syntax. [1] https://stedolan.github.io/jq (note: jq

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:47 AM, Pavel Stehule 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

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 9:40 AM, Pavel Stehule wrote: ​...​ > > ​Hi Pavel, > > > > Can you clarify what you meant? I *think* you're saying: > > > > * It's not important for me to match the syntax/semantics of the > json-path implementations found in MySQL / Oracle / DB2

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ... > Incremental work is great idea - I like this this style. Instead contrib, > you can use public repository on github. Minimally for first stage is > better to live outside core - you are not restricted by

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 5:20 AM, Pavel Stehule wrote: ​...​ > Con: "JSON path expression" is a recurring them in the *grammars* of >> user-facing operators in [1], [2], [3], and [4]. But it doesn't >> necessarily follow that the function implemented in Step 2 will

Re: [HACKERS] Tackling JsonPath support

Dne 28. 11. 2016 17:26 napsal uživatel "David Fetter" : > > On Sun, Nov 27, 2016 at 11:50:30AM -0500, Christian Convey wrote: > > >From looking at other databases' docs, it seems like the behavior of > > various JSON-related operators / functions are described partially in terms

Re: [HACKERS] Tackling JsonPath support

On Sun, Nov 27, 2016 at 11:50:30AM -0500, Christian Convey wrote: > >From looking at other databases' docs, it seems like the behavior of > various JSON-related operators / functions are described partially in terms > of a "json path expression": > > * In Oracle, "JSON_TABLE",

Re: [HACKERS] Tackling JsonPath support

2016-11-27 17:50 GMT+01:00 Christian Convey : > From looking at other databases' docs, it seems like the behavior of > various JSON-related operators / functions are described partially in terms > of a "json path expression": > > * In Oracle, "JSON_TABLE",

Re: [HACKERS] Tackling JsonPath support

>From looking at other databases' docs, it seems like the behavior of various JSON-related operators / functions are described partially in terms of a "json path expression": * In Oracle, "JSON_TABLE", "JSON_exists_column", "JSON_value_column": [1] * In MySQL: [2] * In DB2: [3] * In MS SQL

Re: [HACKERS] Tackling JsonPath support

Hi 2016-11-13 15:14 GMT+01:00 Christian Convey : > Hi Pavel, > > Can I check a few assumptions about what you're suggesting for this task? > > * Our ultimate goal is to give Postgres an implementation of the functions > "JSON_EXISTS", "JSON_VALUE", and "JSON_QUERY"

Re: [HACKERS] Tackling JsonPath support

2016-11-13 18:13 GMT+01:00 Tom Lane : > Christian Convey writes: > > * Our ultimate goal is to give Postgres an implementation of the > functions > > "JSON_EXISTS", "JSON_VALUE", and "JSON_QUERY" which fully comply with the > > SQL standards. > > *

Re: [HACKERS] Tackling JsonPath support

Christian Convey writes: > * Our ultimate goal is to give Postgres an implementation of the functions > "JSON_EXISTS", "JSON_VALUE", and "JSON_QUERY" which fully comply with the > SQL standards. > * The best representation of those standards is found here: [1]. > [1] >

Re: [HACKERS] Tackling JsonPath support

Hi Pavel, Can I check a few assumptions about what you're suggesting for this task? * Our ultimate goal is to give Postgres an implementation of the functions "JSON_EXISTS", "JSON_VALUE", and "JSON_QUERY" which fully comply with the SQL standards. * The best representation of those standards is

Re: [HACKERS] Tackling JsonPath support

Hi 2016-09-15 18:05 GMT+02:00 Christian Convey : > On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule > wrote: > ... > > > I wrote XMLTABLE function, and I am thinking about JSON_TABLE function. > But > > there is one blocker - missing JsonPath

[HACKERS] Tackling JsonPath support

On Mon, Sep 5, 2016 at 1:44 PM, Pavel Stehule wrote: ... > I wrote XMLTABLE function, and I am thinking about JSON_TABLE function. But > there is one blocker - missing JsonPath support in our JSON implementation. > > So one idea - implement JsonPath support and related