* Andrew Dunstan (andrew@dunslane.net) wrote:
> This looks too clever by half, to me. Someone facing the problem you are
> facing would have to dig quite deep to find the solution you're promoting.
Oddly enough, it was one of the first things I tried when I discovered
it wasn't just realizing that ,"", for an integer column meant NULL (and
instead was complaining loudly that you can't convert an empty string
into an integer). It's also pretty clear, to me at least, to say
"put the exact string that shows up between the delimiters here
that you want treated as a NULL" rather than "well, if it's a column
which is quoted then you have to jump through these hoops and tell PG
about each one, but if it's not quoted you have to do this", etc, etc.
> A much better way IMNSHO would be to add an extra FORCE switch. On input,
> FORCE NOT NULL says to treat an unquoted null as the literal value rather
> than as a null field for the columns named. The reverse would be to tell it
> to treat a quoted null as null rather than as the literal value, for the
> named columns. Perhaps that should just be "FORCE NULL columnlist". It
> would be more explicit and at the same time would only apply to the named
> columns, rather than discarding totally the ability to distinguish between
> null and not null values.
I don't see that it needs to be 'more explicit', that's just silly.
Either the user indicated they want it, or they didn't. What you're
suggesting adds in a bunch of, imv, unnecessary complication and ends up
making the resulting code that much bigger and uglier for not much gain.
I'm honestly not a big fan of the "columnlist" approach that's been
taken with the options. While I understand the desire to seperate the
parsing from the typing, making the users essentially do that association
for us by way of making them specify how to handle each column explicitly
is worse than just accepting that different types may need to be handled
in different ways.
We could instead flip it around and force the users to specify, for
each column, what, exactly, should be done for that column by having
them specify a regexp for that column. The regexp would implicitly have
the delimiter on each side of it and we'd just step through the string
matching as far as we can for each column. Then it's nice and explicit
for everyone but probably not much fun to use.
> This should probably be discussed on -hackers, anyway.
As a small, unobtrusive patch, I felt it didn't need a long discussion
about what everyone's CSV files look like and how "that just shouldn't
be done" or "that's just not sane."
Thanks,
Stephen
