From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Add basic JSON_TABLE() functionality |
Date: | 2024-04-05 02:52:33 |
Message-ID: | CA+HiwqH4a3T0kyxV2akpKfGa+W+RsmOriH_ZTjEKzVZ-=DAptQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Fri, Apr 5, 2024 at 1:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > We need to either nuke that ecpg warning entirely, or find a more
> > robust way of detecting whether the gram.y complaint is conditional.
> > I'll put a brown paper bag on my head before suggesting that maybe
> > we could pay attention to how far the errcode is indented. Perhaps
> > a slightly nicer way is to assume it's conditional if any earlier
> > line in the rule starts with "if".
>
> The latter seems considerably safer, so I modified parse.pl along
> those lines. Eyeball comparison of gram.y with preproc.y verifies
> that now ecpg will emit the warning only in rules where the backend
> unconditionally reports FEATURE_NOT_SUPPORTED.
>
> I suppose this needs to be back-patched.
Thanks for taking care of this and the missing .gitignore entries as well.
Just to make a correction to what I said upthread in reply to Andrew,
it seems like I did get the WARNING but missed it.
Wonder if, for consistency, I should change the coding so that the
FEATURE_NOT_SUPPORTED is reported in transformJsonTable() or
something?
--
Thanks, Amit Langote
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-05 02:56:13 | Re: pgsql: Add basic JSON_TABLE() functionality |
Previous Message | Michael Paquier | 2024-04-05 00:04:37 | pgsql: Add "ABI_compatibility" regions to wait_event_names.txt |