Fix trailing SQL comments breaking multiline submit and execution - #1559
Merged
Merged
Conversation
Two bugs when a comment follows the semicolon (e.g. "SELECT 1; -- note"):
1. pgbuffer._is_complete() checked sql.endswith(";") which returned False
when a comment followed, preventing multiline mode from ever submitting
2. pgexecute.run() used rstrip(";") which couldn't find the semicolon
past the trailing comment, sending malformed SQL to PostgreSQL
Both fixes strip comments (via sqlparse) before checking for the semicolon.
Made with ❤️ and 🤖 Claude
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Contributor
|
One of the integration tests is failing. |
With strip_comments=True, trailing comments after \h are correctly removed, so \h now shows full help output instead of "No help". The original test expectations were based on a sqlparse bug where comments were kept as arguments — the upstream TODO comments acknowledged this was undesired behavior.
Long asserts were split unnecessarily; ruff 0.15.11 keeps them on a single line (line-length=140).
Contributor
Author
|
Merged latest |
Contributor
Author
Contributor
|
Ok, all green. Merging. Thank you! |
This was referenced Jun 3, 2026
DiegoDAF
added a commit
to DiegoDAF/pgcli.daf
that referenced
this pull request
Sep 21, 2026
select 17 # 5 returned 17 instead of 20, and said nothing about it. sqlparse follows MySQL and reads # as the start of a comment, so sqlparse.format(strip_comments=True) dropped the rest of the line before the statement was sent. Reported upstream as dbcli#1646; the sqlparse side is andialbrecht/sqlparse#539. Worth saying plainly: we introduced this. Our dbcli#1559 changed that call from strip_comments=False to True so that rstrip(";") would work with a comment after the semicolon. It fixed that and broke this. The intent of dbcli#1559 only needs the TRAILING comments gone, so strip_trailing_comments() now does exactly that, with PostgreSQL's rules rather than sqlparse's: -- to end of line, /* */ which nest, and no comment markers honoured inside string literals, quoted identifiers or dollar-quoted bodies. A comment in the middle of a statement is kept, as the server would see it. # is just an operator. Both call sites move over: the one before execution in pgexecute, and _is_complete() in pgbuffer, where "select 17 # 5;" would otherwise never look finished. 15 tests.
3 tasks
DiegoDAF
added a commit
to DiegoDAF/pgcli.daf
that referenced
this pull request
Sep 21, 2026
Fixes dbcli#1646. > select 17 # 5; +----------+ | ?column? | |----------| | 17 | +----------+ The answer is 20. sqlparse follows MySQL and reads # as the start of a comment (andialbrecht/sqlparse#539), so sqlparse.format(strip_comments=True) dropped the rest of the line before the statement reached the server, and the wrong answer came back without a warning. Only the TRAILING comments need to go there, which is what that call was added for in dbcli#1559: rstrip(";") cannot find the semicolon when a comment follows it. strip_trailing_comments() does that with PostgreSQL's rules instead of sqlparse's: - "--" runs to the end of the line, "/* */" nest; - those markers mean nothing inside a string literal, a quoted identifier or a dollar-quoted body; - "#" is an operator like any other. A comment in the middle of a statement is kept, so the server sees what was written. Both call sites move over: the one before execution in pgexecute, and _is_complete() in pgbuffer, where "select 17 # 5;" would otherwise never look finished and the prompt would keep waiting. 18 tests, including nested block comments, dollar-quoted function bodies, doubled quotes inside strings and unterminated comments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two related bugs when a SQL comment follows the semicolon, e.g.:
Bug 1 —
pgbuffer._is_complete():sql.endswith(";")returnedFalsewhen a trailing comment followed the semicolon. In multiline mode, pressing Enter never submitted the query — the UI appeared frozen.Bug 2 —
pgexecute.run():sql.rstrip(";")couldn't strip the semicolon because the string ended with the comment text, not;. The malformed SQL (with embedded;) was sent to PostgreSQL via psycopg's extended query protocol, which doesn't support multiple statements.Fix
Both locations now use
sqlparse.format(sql, strip_comments=True)before checking for / removing the trailing semicolon.Files Changed
pgcli/pgbuffer.py—_is_complete()strips comments beforeendswith(";")pgcli/pgexecute.py—run()strips comments beforerstrip(";")changelog.rst— Added bug fix entry to Upcomingtests/test_trailing_comments.py— 12 new tests covering edge casesTest plan
pytest tests/test_trailing_comments.py -v)vacuum freeze verbose tpd.file_delivery; -- 82% towards emergencyexecutes correctly