It is my understanding that \N is a valid column value (no backslash
escape in CSV, right?), so we can't use it for NULL.
\ is not conventionally magical in CSVs in the general case. That doesn't mean we couldn't use \N, but to me it would violate the principle of least surprise - no other application will interpret it in any special way, and the whole point about this facility is exchanging data with other applications.
The only thing I can think of is for NULL to be:
,,
(no quotes) and a zero-length string to be:
,"",
How do most applications handle those two cases? If they accept either, can we use that so we can read our own CSV files without losing the NULL specification?
In fact, in the patch I sent in, no quoted string is marked as null when being read (so even if you use \N as the null marker, "\N" will be that literal and not a null marker). And the null marker, whatever it is, should be made quote safe by us throwing an error if it contains the quote marker, just as we now make sure that the null marker is delimiter-safe.
I will check on the write behaviour - it might need ammending too.
I'll submit a revised patch based on the original syntax scheme, and then you (Bruce) can make the syntax/psql changes that seem to be agreed on now - is that ok?
The default NULL value issue can be determined at the end of any exhaustive debate we have - in the end it's a one line code change ;-)
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
