Repository navigation
Capture the COPY ... FROM STDIN payload verbatim - #2428
Open
LucaCappelletti94 wants to merge 1 commit into
Open
LucaCappelletti94 wants to merge 1 commit into
LucaCappelletti94 wants to merge 1 commit into
Conversation
LucaCappelletti94
marked this pull request as ready for review
August 4, 2026 20:28
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
2 times, most recently
from
August 24, 2026 11:50
5c2e10e to
de77ad2
Compare
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
from
September 3, 2026 17:05
de77ad2 to
35a7fe0
Compare
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
4 times, most recently
from
September 22, 2026 21:20
01250ba to
75ca5f6
Compare
LucaCappelletti94
added a commit
to LucaCappelletti94/sqlparser-rs
that referenced
this pull request
Oct 2, 2026
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2428 +/- ##
==========================================
+ Coverage 81.28% 81.31% +0.03%
==========================================
Files 42 42
Lines 33920 33906 -14
Branches 33920 33906 -14
==========================================
- Hits 27571 27570 -1
+ Misses 2785 2772 -13
Partials 3564 3564 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
from
October 2, 2026 16:15
d9944b2 to
652c896
Compare
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
from
October 17, 2026 01:00
652c896 to
d3d3881
Compare
LucaCappelletti94
force-pushed
the
copy-stdin-verbatim-payload
branch
from
October 18, 2026 14:08
d3d3881 to
74d64d8
Compare
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
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.
Parsing
COPY t (a, b) FROM stdin;with two rows of two columns produced six values with nothing marking where the first row ended, so the rows could not be recovered even by counting columns. Printing the statement did not reproduce its input either, and every print and re-parse cycle inserted one more tab before each field, without bound.The cause is that the payload was being split on tabs and newlines with
\Ninterpreted, which is a partial implementation of the PostgreSQL text format. This removes that rather than completing it.Statement::Copynow carriespayload: Option<String>, holding the text between the command and the\.terminator exactly as written, andDisplaywrites it back unchanged. What a tab or a\Nmeans is left to whoever consumes the statement.Nonemeans the statement carried no inline data, so a bareCOPY t FROM STDIN;still prints without an invented terminator, whileSome("")is an explicitly empty payload.This breaks
Statement::Copy, andParser::parse_tsvandParser::parse_tab_valueare removed along with the format handling. Every otherCOPYsub-parser was already private.My suggestion here is that either we go full csv parsing (which I agree might be a bit much), or no parsing at all (which is what I am suggesting we do in this PR), as the current impl was neither and broken.