Re: SQL/JSON in PostgreSQL

From: Piotr Stefaniak <email(at)piotr-stefaniak(dot)me>
To: "obartunov(at)gmail(dot)com" <obartunov(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: SQL/JSON in PostgreSQL
Date: 2017-11-02 21:32:51
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 2017-02-28 20:08, Oleg Bartunov wrote:
> Attached patch is an implementation of SQL/JSON data model from SQL-2016
> standard (ISO/IEC 9075-2:2016(E))

I've faintly started looking into this.

> We created repository for reviewing (ask for write access) -

> Examples of usage can be found in src/test/regress/sql/sql_json.sql

> The whole documentation about json support should be reorganized and added,
> and we plan to do this before release. We need help of community here.

> The standard describes SQL/JSON path language, which used by SQL/JSON query
> operators to query JSON. It defines path language as string literal. We
> implemented the path language as JSONPATH data type, since other
> approaches are not friendly to planner and executor.

I was a bit sad to discover that I can't
I assume because of this part of the updated grammar:
Sconst { $$ = $1; }

Would it make sense, fundamentally, to allow variables there? After
Andrew Gierth's analysis of this grammar problem, I understand that it's
not reasonable to expect JSON_TABLE() to support variable jsonpaths, but
maybe it would be feasible for everything else? From Andrew's changes to
the new grammar (see attached) it seems to me that at least that part is
possible. Or should I forget about trying to implement the other part?

Attachment Content-Type Size
gram.diff text/x-patch 1.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2017-11-02 22:00:35 Re: MERGE SQL Statement for PG11
Previous Message Tom Lane 2017-11-02 21:29:30 Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM