| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Christian Convey <christian(dot)convey(at)gmail(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-11-29 16:28:38 |
| Message-ID: | 20161129162837.GF24797@localhost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 on top of that). I think that should give us
> some hint on what the base functionality should look like.
Yes, that'd be base functionality. You can go above and beyond.
I agree with Pavel that jq could be used as a user-defined function, but
proper integration would be better because it would avoid the need to
format and parse JSON around calls to jq, and also because PG could
compile jq programs when preparing SQL statements. Besides, the libjq
jv API is *very* nice.
Nico
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2016-11-29 16:38:30 | Re: Tackling JsonPath support |
| Previous Message | Petr Jelinek | 2016-11-29 16:18:17 | Re: Tackling JsonPath support |