From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Add basic JSON_TABLE() functionality
Date: Thu, 04 Apr 2024 12:55:08 -0400
Message-ID: <655689.1712249708@sss.pgh.pa.us> (raw)
In-Reply-To: <603615.1712245382@sss.pgh.pa.us>
References: <E1rsL9y-000S60-Pn@gemulon.postgresql.org>
<f8402aef-c66c-4207-992c-fdee5e59c612@dunslane.net>
<CA+HiwqF8KeHyoNi8TM-fUuE_002GYANbM55ybqEWi5QRinX5YQ@mail.gmail.com>
<49c3a0cc-2998-4e25-8bc3-e70b3cba87eb@dunslane.net>
<601996.1712244407@sss.pgh.pa.us>
<603615.1712245382@sss.pgh.pa.us>
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.
regards, tom lane
Attachments:suppress-inappropriate-ecpg-warnings.patch (text/x-diff, 1.9K) downloaddiff --git a/src/interfaces/ecpg/preproc/parse.pl b/src/interfaces/ecpg/preproc/parse.plindex 87b512b2a1..fe8d3e5178 100644--- a/src/interfaces/ecpg/preproc/parse.pl+++ b/src/interfaces/ecpg/preproc/parse.pl@@ -34,7 +34,8 @@ my $brace_indent = 0;
my $yaccmode = 0;
my $in_rule = 0;
my $header_included = 0;
-my $feature_not_supported = 0;+my $has_feature_not_supported = 0;+my $has_if_command = 0;
my $tokenmode = 0;
my (%buff, $infield, $comment, %tokens, %addons);
@@ -151,12 +152,6 @@ sub main
{
line: while (<$parserfh>)
{
- if (/ERRCODE_FEATURE_NOT_SUPPORTED/)- {- $feature_not_supported = 1;- next line;- }-
chomp;
# comment out the line below to make the result file match (blank line wise)
@@ -182,6 +177,13 @@ sub main
$infield = 0;
}
+ if ($yaccmode == 1)+ {+ # Check for rules that throw FEATURE_NOT_SUPPORTED+ $has_feature_not_supported = 1 if /ERRCODE_FEATURE_NOT_SUPPORTED/;+ $has_if_command = 1 if /^\s*if/;+ }+
my $prec = 0;
# Make sure any braces are split
@@ -541,20 +543,17 @@ sub dump_fields
#Normal
add_to_buffer('rules', $ln);
- if ($feature_not_supported == 1)+ if ($has_feature_not_supported and not $has_if_command)
{
-- # we found an unsupported feature, but we have to- # filter out ExecuteStmt: CREATE OptTemp TABLE ...- # because the warning there is only valid in some situations- if ($flds->[0] ne 'create' || $flds->[2] ne 'table')- {- add_to_buffer('rules',- 'mmerror(PARSE_ERROR, ET_WARNING, "unsupported feature will be passed to server");'- );- }- $feature_not_supported = 0;+ # The backend unconditionally reports+ # FEATURE_NOT_SUPPORTED in this rule, so let's emit+ # a warning on the ecpg side.+ add_to_buffer('rules',+ 'mmerror(PARSE_ERROR, ET_WARNING, "unsupported feature will be passed to server");'+ );
}
+ $has_feature_not_supported = 0;+ $has_if_command = 0;
if ($len == 0)
{
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, amitlangote09@gmail.com, andrew@dunslane.net, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Add basic JSON_TABLE() functionality
In-Reply-To: <655689.1712249708@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox