Hi,
Thanks for the review!

On 04/11/2026 07:54, Chao Li wrote:
ERROR:  column name mismatch in header line field 2: got null value ("a"), expected 
"a"
CONTEXT:  COPY t, line 1: "id,a"
```

Here, a is a valid column name in the header line and should not be rejected 
simply because it matches the NULL marker.

Adding an is_header parameter allows us to disable both NULL and DEFAULT marker 
recognition when parsing header lines, addressing both issues with the same 
approach. It also avoids temporarily modifying the COPY options.

So, I’m proposing v2 with this approach. I kept the regression tests you added 
in v1 and added tests for NULL markers and the text format. Would you please 
review v2?
I have mixed feelings about this:

CREATE TABLE t (id int, "N" text);

If user inputs this in COPY:
id   \N
1    \N

same is in diffed existing regression test for it:

|-ERROR: column name mismatch in header line field 3: got null value ("\N"), expected "c" +ERROR: column name mismatch in header line field 3: got "N", expected "c"|

IMO, i prefer having this error out for NULL marker reason in a column name, rather than reading '\N' as 'N' in header, and this might be the intention of who wrote it... maybe. I agree this should be data rows only, but the documentation doesn't specify that either, at least not as expected as the case of DEFAULT marker. So i'm not sure...

CSV case:
In CSV, CopyReadAttributesCSV() already checks `!saw_quote`. If a user has a
column named "a" and sets `null 'a'`, quoting the column name in the header (`id,"a"`) already prevents it from being treated as NULL.


I have an extra worry about performance regressions, previously from [1], i saw that very minimal changes effect the binary layout and branching (without going into much details), therefore having 1-3% performance regressions or improvements that appear just like that (this applies everywhere in Postgres really...), CopyReadAttributesCSV() is very sensitive, it runs millions of times very easily and its a high registers-pressured code.

A not too serious benchmark on v2 already shows 5% regressions.


Regards,
Ayoub Kazar

[1] https://www.postgresql.org/message-id/CAOzEurSW8cNr6TPKsjrstnPfhf4QyQqB4tnPXGGe8N4e_v7Jig%40mail.gmail.com

Reply via email to