When this bit of commentary was written, it was alluding to the
fact that we looked for newlines and EOD markers in the raw
(not yet encoding-converted) input data. We don't do that anymore,
preferring to batch the conversion of larger chunks of input and
split it into lines later. Hence there's no longer any need for
assumptions about the relevant characters being encoding-invariant,
and we should remove this comment saying we assume that.
Discussion: https://postgr.es/m/
1461688.
1712347668@sss.pgh.pa.us
* value and are put in line_buf. We keep just enough state to know if we
* are currently in a quoted field or not.
*
- * These four characters, and the CSV escape and quote characters, are
- * assumed the same in frontend and backend encodings.
- *
* The input has already been converted to the database encoding. All
* supported server encodings have the property that all bytes in a
* multi-byte sequence have the high bit set, so a multibyte character