Manfred Koizar <mkoi-pg@aon.at> writes:
> To be clear, this is not about \N as the default external
> representation for NULL, I'm talking about a string consisting of the
> two characters backslash and uppercase-N.
Now that I look at it, this must have been broken since the beginning of
time, or at least since we made the null representation configurable.
Surprising no one noticed before.
The problem is that the WITH NULL string is compared to the attribute
value *after* debackslashing, and so there is no way to prevent a match
to an actual valid data string.
In older code it seems that the representation of NULL as \N was
hardwired, and this was tested for in the process of debackslashing,
so that the valid data string \\N wouldn't be mistaken for \N.
For the purposes of recognizing the default \N null representation,
it seems we have to compare the null representation string to the
pre-debackslashing input. (This is probably fairly easy to make happen
in CVS tip, but it might be pretty painful in 7.3.) Arguably this is
the right semantics because in the other direction we don't backslash
the outgoing null-representation string. I wonder whether it would
break any existing apps though.
Comments?
regards, tom lane