Re: Tackling JsonPath support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Christian Convey <christian(dot)convey(at)gmail(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Nico Williams <nico(at)cryptonector(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Tackling JsonPath support
Date: 2016-12-02 13:53:33
Message-ID: CA+TgmoZ28byiVjXTHO=B3jbOWcVk7dVySvJGc7wBF0ecPjOBhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey
<christian(dot)convey(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-12-02 13:59:42 Re: s/xlog/wal/ in tools and function names?
Previous Message Robert Haas 2016-12-02 13:37:20 Re: Write Ahead Logging for Hash Indexes