Re: Tackling JsonPath support - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Tackling JsonPath support
Date
Msg-id CA+TgmoZ28byiVjXTHO=B3jbOWcVk7dVySvJGc7wBF0ecPjOBhg@mail.gmail.com
Whole thread Raw
In response to Re: Tackling JsonPath support  (Christian Convey <christian.convey@gmail.com>)
Responses Re: Tackling JsonPath support
List pgsql-hackers
On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey
<christian.convey@gmail.com> 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 really know whether
JSONPath is the right standard to pick for the task of extracting bits
of JSON from other bits of JSON, but I think there's some value in
picking something is simple enough that we can implement it in our own
code and not have to rely on a third-party library.  Of course, if
somebody feels like adding a configure option for --with-jq and
appropriate interfaces to integrate with JQ, we could consider that,
too, but that imposes a packaging requirement that a home-grown
implementation doesn't.  I'd want to hear more than one vote for such
a course of action before embracing it.  If JQ is a Turing-complete
query language, integrating it might be quite difficult -- for
example, we'd need a way to make sure that it does periodic
CHECK_FOR_INTERRUPTS() calls, and that it doesn't leak resources or
crash if those calls decide longjmp() away due to an ERROR -- and
would we let people query database tables with it?  Would that be
efficient?  I think it's fine to have more limited objectives than
what a JQ implementation would apparently entail.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Write Ahead Logging for Hash Indexes
Next
From: Michael Paquier
Date:
Subject: Re: s/xlog/wal/ in tools and function names?