]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 Apr 2024 19:31:53 +0000 (15:31 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 Apr 2024 19:31:53 +0000 (15:31 -0400)
commit360d007e3193b98c3a97953e8d1f874d89044330
treea89058ee6061912fe7d2f79776907422ea47b970
parent38585549a3ef96fbbd8a1e7c86dc1b4b8ee5faa8
Fix ecpg's mechanism for detecting unsupported cases in the grammar.

ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for.  The way it was testing for this was to see if the string
ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code.
This is, of course, not nearly good enough, as there are plenty of
rules in gram.y that throw that error only conditionally.  There was
a hack dating to 2008 to suppress the warning in one rule that
doesn't even exist anymore, but nothing for other cases we've created
since then.  End result was that you could get "unsupported feature
will be passed to server" warnings while compiling perfectly good SQL
code in ecpg.  Somehow we'd not heard complaints about this, but
it was exposed by the recent addition of an ecpg test for a SQL/JSON
construct.

To fix, suppress the warning if the rule contains any "if" statement.
Manual comparison of gram.y with the generated preproc.y file shows
that the warning is now emitted only in rules where it's sensible.

This problem has existed for a long time, so back-patch to all
supported branches.

Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us
src/interfaces/ecpg/preproc/parse.pl