| From: | David Fetter <david(at)fetter(dot)org> |
|---|---|
| To: | Christian Convey <christian(dot)convey(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Tackling JsonPath support |
| Date: | 2016-11-28 16:26:39 |
| Message-ID: | 20161128162639.GB27143@fetter.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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", "JSON_exists_column", "JSON_value_column": [1]
> * In MySQL: [2]
> * In DB2: [3]
> * In MS SQL Server: [4]
> * (Whatever the Standards committee will end up producing.)
There's another option we should also consider: jq
<https://stedolan.github.io/jq/>. It's available under a
PostgreSQL-compatible license, and has had a LOT of work put into
correctness and performance.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nico Williams | 2016-11-28 16:44:48 | Re: Alternative MATERIALIZED VIEW design and implementation with history table and other features |
| Previous Message | Fabien COELHO | 2016-11-28 15:53:31 | Re: [PATCH] pgpassfile connection option |