From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: remaining sql/json patches |
Date: | 2023-07-20 08:19:02 |
Message-ID: | CA+HiwqGR93pZY7gDkQHtD-K1rOgFiL9u3nY3H1VixAgkrGKOtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 19, 2023 at 5:17 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Wed, Jul 19, 2023 at 12:53 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > On 2023-Jul-18, Amit Langote wrote:
> >
> > > Attached updated patches. In 0002, I removed the mention of the
> > > RETURNING clause in the JSON(), JSON_SCALAR() documentation, which I
> > > had forgotten to do in the last version which removed its support in
> > > code.
> >
> > > I think 0001 looks ready to go. Alvaro?
> >
> > It looks reasonable to me.
>
> Thanks for taking another look.
>
> I will push this tomorrow.
Pushed.
> > > Also, I've been wondering if it isn't too late to apply the following
> > > to v16 too, so as to make the code look similar in both branches:
> >
> > Hmm.
> >
> > > 785480c953 Pass constructName to transformJsonValueExpr()
> >
> > I think 785480c953 can easily be considered a bugfix on 7081ac46ace8, so
> > I agree it's better to apply it to 16.
>
> OK.
Pushed to 16.
> > > b6e1157e7d Don't include CaseTestExpr in JsonValueExpr.formatted_expr
> >
> > I feel a bit uneasy about this one. It seems to assume that
> > formatted_expr is always set, but at the same time it's not obvious that
> > it is. (Maybe this aspect just needs some more commentary).
>
> Hmm, I agree that the comments about formatted_expr could be improved
> further, for which I propose the attached. Actually, staring some
> more at this, I'm inclined to change makeJsonValueExpr() to allow
> callers to pass it the finished 'formatted_expr' rather than set it by
> themselves.
>
> > I agree
> > that it would be better to make both branches identical, because if
> > there's a problem, we are better equipped to get a fix done to both.
> >
> > As for the removal of makeCaseTestExpr(), I agree -- of the six callers
> > of makeNode(CastTestExpr), only two of them would be able to use the new
> > function, so it doesn't look of general enough usefulness.
>
> OK, so you agree with back-patching this one too, though perhaps only
> after applying something like the aforementioned patch.
I looked at this some more and concluded that it's fine to think that
all JsonValueExpr nodes leaving the parser have their formatted_expr
set. I've updated the commentary some more in the patch attached as
0001.
Rebased SQL/JSON patches also attached. I've fixed the JSON_TABLE
syntax synopsis in the documentation as mentioned in my other email.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
v9-0001-Code-review-for-commit-b6e1157e7d.patch | application/octet-stream | 6.1 KB |
v9-0002-SQL-JSON-functions.patch | application/octet-stream | 50.5 KB |
v9-0005-Claim-SQL-standard-compliance-for-SQL-JSON-featur.patch | application/octet-stream | 2.3 KB |
v9-0004-JSON_TABLE.patch | application/octet-stream | 164.2 KB |
v9-0003-SQL-JSON-query-functions.patch | application/octet-stream | 209.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2023-07-20 08:36:48 | Re: Performance degradation on concurrent COPY into a single relation in PG16. |
Previous Message | Daniel Gustafsson | 2023-07-20 07:34:29 | Re: Assertion failure in SnapBuildInitialSnapshot() |