From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com> |
Subject: | Re: remaining sql/json patches |
Date: | 2024-03-07 14:23:56 |
Message-ID: | CA+HiwqFUpwwGhy4-w70dHxfmrxefvzniUcJAm-7sv76J+Ezu-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 7, 2024 at 23:14 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2024-Mar-07, Tomas Vondra wrote:
>
> > I was experimenting with the v42 patches, and I think the handling of ON
> > EMPTY / ON ERROR clauses may need some improvement.
>
> Well, the 2023 standard says things like
>
> <JSON value function> ::=
> JSON_VALUE <left paren>
> <JSON API common syntax>
> [ <JSON returning clause> ]
> [ <JSON value empty behavior> ON EMPTY ]
> [ <JSON value error behavior> ON ERROR ]
> <right paren>
>
> which implies that if you specify it the other way around, it's a syntax
> error.
>
> > I'm not sure what the SQL standard says about this, but it seems other
> > databases don't agree on the order. Is there a particular reason to
> > not allow both orderings?
>
> I vaguely recall that trying to also support the other ordering leads to
> having more rules.
Yeah, I think that was it. At one point, I removed rules supporting syntax
that wasn’t documented.
Now maybe we do want that because of compatibility
> with other DBMSs, but frankly at this stage I wouldn't bother.
+1.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-03-07 14:51:43 | Re: POC, WIP: OR-clause support for indexes |
Previous Message | Robert Haas | 2024-03-07 14:16:47 | Re: Add system identifier to backup manifest |