pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix plpgsql's handling of -- comments following expressions. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5e9d8bed0094b146d64013d417c51eb0f69aeafd Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 ++++++++++ src/pl/plpgsql/src/pl_gram.y | 43 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 ++++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 74 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f5cee411a1903fdad9d60c80022fbe4ad3c4d519 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 ++++++++++ src/pl/plpgsql/src/pl_gram.y | 43 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 ++++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 74 insertions(+), 34 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5392dd3d2ad5a371c95e648442fd121d8a8a5c42 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 +++++++++ src/pl/plpgsql/src/pl_gram.y | 47 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 +++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 76 insertions(+), 36 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dc5824a06e979e1f4412849d63d166ca16d1f84d Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 +++++++++ src/pl/plpgsql/src/pl_gram.y | 47 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 +++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 76 insertions(+), 36 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/48f216dc634bcda522c92de7de61036fdc26847f Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 +++++++++ src/pl/plpgsql/src/pl_gram.y | 47 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 +++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 76 insertions(+), 36 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix plpgsql's handling of -- comments following expressions. @ 2024-04-10 19:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-04-10 19:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix plpgsql's handling of -- comments following expressions. Up to now, read_sql_construct() has collected all the source text from the statement or expression's initial token up to the character just before the "until" token. It normally tries to strip trailing whitespace from that, largely for neatness. If there was a "-- text" comment after the expression, this resulted in removing the newline that terminates the comment, which creates a hazard if we try to paste the collected text into a larger SQL construct without inserting a newline after it. In particular this caused our handling of CASE constructs to fail if there's a comment after a WHEN expression. Commit 4adead1d2 noticed a similar problem with cursor arguments, and worked around it through the rather crude hack of suppressing the whitespace-trimming behavior for those. Rather than do that and leave the hazard open for future hackers to trip over, let's fix it properly. pl_scanner.c already has enough infrastructure to report the end location of the expression's last token, so we can copy up to that location and never collect any trailing whitespace or comment to begin with. Erik Wienhold and Tom Lane, per report from Michal Bartak. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d85db0a8e95cb7284a288d18f6fe48afde65c9f9 Modified Files -------------- src/pl/plpgsql/src/expected/plpgsql_control.out | 17 +++++++++ src/pl/plpgsql/src/pl_gram.y | 47 +++++++++++-------------- src/pl/plpgsql/src/pl_scanner.c | 17 +++++++++ src/pl/plpgsql/src/plpgsql.h | 1 + src/pl/plpgsql/src/sql/plpgsql_control.sql | 14 ++++++++ src/test/regress/expected/plpgsql.out | 8 ++--- src/test/regress/sql/plpgsql.sql | 8 ++--- 7 files changed, 76 insertions(+), 36 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-04-10 19:46 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. Tom Lane <tgl@sss.pgh.pa.us> 2024-04-10 19:46 pgsql: Fix plpgsql's handling of -- comments following expressions. 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