On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey <christian.con...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers