Bruce Momjian wrote:
>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
