pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/096a761d687f1f60dc581f388f8e5b11d648b290 Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/118558e6d46b512d2ba04d7fc799c5750305ce71 Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f159f1814156764d20a27b63d334ab302e68e59a Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d3167ed3f7cde873f356673ce9b742f4177924a4 Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5ba29e9454de1ec50d3f00c33a60bfa0d8cb7af0 Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram @ 2024-04-04 19:32 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-04 19:32 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/360d007e3193b98c3a97953e8d1f874d89044330 Modified Files -------------- src/interfaces/ecpg/preproc/parse.pl | 37 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 19 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-04-04 19:32 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us> 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us> 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us> 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us> 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us> 2024-04-04 19:32 pgsql: Fix ecpg's mechanism for detecting unsupported cases in the gram Tom Lane <tgl@sss.pgh.pa.us>
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