Re: Plan for CSV handling of quotes, NULL

Bruce Momjian said:
> Tom Lane wrote:
>> TypeCategory is a crock that should have been done away with long ago.
>> We need to be working to eliminate it, not expand our dependency on
>> it.
>
> Ah, so do we have any other way to identify the type of field we are
> using? Particularly, how do we identify a numeric and dates?
>
> If we don't find something, we have to push those decisions to the
> user, which is kind of strange because deep down we must know this.
>

To be honest, I would feel safer with the decision in the hands of users.
They know their data and needs better than we do. Continuing with the zip
code example, if the foreign program is another db, the same problem
should not arise as there is in a spreadsheet, because it should know the
data type it is importing into, just like we do. Since we don't know what
the foreign program is, we would be making a "worst case" guess. With user
choice, we would be quoting in exactly these circumstances:

. looks like the null string but isn't null
. contains the quote or delimiter chars
. isn't null and the user told us to

I don't think it unduly burdensome. Using the syntax I suggested earlier,
something like:

copy mytable to 'mydata.csv' csv force zipcode;

seems OK to me. I'm all in favor of low-tecH solutions where
appropriate. ;-)

cheers

andrew