Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rsQMx-006xkf-Cj for pgsql-committers@arkaria.postgresql.org; Thu, 04 Apr 2024 16:55:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rsQMw-009EvG-4q for pgsql-committers@arkaria.postgresql.org; Thu, 04 Apr 2024 16:55:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rsQMv-009Ev8-Th for pgsql-committers@lists.postgresql.org; Thu, 04 Apr 2024 16:55:17 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rsQMp-000dOI-2O for pgsql-committers@lists.postgresql.org; Thu, 04 Apr 2024 16:55:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 434Gt8Zr655690; Thu, 4 Apr 2024 12:55:08 -0400 From: Tom Lane To: Amit Langote cc: Andrew Dunstan , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Add basic JSON_TABLE() functionality In-reply-to: <603615.1712245382@sss.pgh.pa.us> References: <49c3a0cc-2998-4e25-8bc3-e70b3cba87eb@dunslane.net> <601996.1712244407@sss.pgh.pa.us> <603615.1712245382@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 04 Apr 2024 11:43:02 -0400" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <655658.1712249696.0@sss.pgh.pa.us> Date: Thu, 04 Apr 2024 12:55:08 -0400 Message-ID: <655689.1712249708@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <655658.1712249696.1@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 ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="suppress-inappropriate-ecpg-warnings.patch"; charset="us-ascii" Content-ID: <655658.1712249696.2@sss.pgh.pa.us> Content-Description: suppress-inappropriate-ecpg-warnings.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/interfaces/ecpg/preproc/parse.pl b/src/interfaces/ecpg/pr= eproc/parse.pl index 87b512b2a1..fe8d3e5178 100644 --- a/src/interfaces/ecpg/preproc/parse.pl +++ b/src/interfaces/ecpg/preproc/parse.pl @@ -34,7 +34,8 @@ my $brace_indent =3D 0; my $yaccmode =3D 0; my $in_rule =3D 0; my $header_included =3D 0; -my $feature_not_supported =3D 0; +my $has_feature_not_supported =3D 0; +my $has_if_command =3D 0; my $tokenmode =3D 0; = my (%buff, $infield, $comment, %tokens, %addons); @@ -151,12 +152,6 @@ sub main { line: while (<$parserfh>) { - if (/ERRCODE_FEATURE_NOT_SUPPORTED/) - { - $feature_not_supported =3D 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 =3D 0; } = + if ($yaccmode =3D=3D 1) + { + # Check for rules that throw FEATURE_NOT_SUPPORTED + $has_feature_not_supported =3D 1 if /ERRCODE_FEATURE_NOT_SUPPORTED/; + $has_if_command =3D 1 if /^\s*if/; + } + my $prec =3D 0; = # Make sure any braces are split @@ -541,20 +543,17 @@ sub dump_fields = #Normal add_to_buffer('rules', $ln); - if ($feature_not_supported =3D=3D 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 passe= d to server");' - ); - } - $feature_not_supported =3D 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 =3D 0; + $has_if_command =3D 0; = if ($len =3D=3D 0) { ------- =_aaaaaaaaaa0--