Darcy Buskermolen wrote:
+ CSV mode will include all characters between
+ <literal>DELIMITER</> in the value for the field, this is of
+ attention to those who use CSV mode to import data from other
+ systems that create fixed width CSV files.
First, this need some grammar cleanup. But more importantly, it's not
quite a correct formulation. CSV mode splits a line on (unquoted)
delimiters. Within each chunk dequoting is done, and withing quoted
sections de-escaping is done. But nothing is discarded.
i.e. with the quote char as '"', 'foo"bar"baz' becomes 'foobarbaz' and
' "x" ' becomes ' x '.
I understand Dary's problem has been that Oracle pads CSV lines with
spaces. Perhaps we need to warn specifically about that - I suspect
most people for whom it might be important will miss the significance
I'll work on some better wording.
How about this?
In CSV mode all characters are significant. A quoted value surrounded by
white space, or any characters other than <literal>DELIMITER</>, will
include those characters. This can cause errors if you import data from
a system that pads CSV lines with white space out to some fixed width.
If such a situation arises you might need to preprocess the CSV file to
remove the trailing white space, before importing the data into Postgres.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not