Re: Plan for CSV handling of quotes, NULL

Andrew Dunstan wrote:
> 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. ;-)

We could do smart defaults and let folks control it too. That would
work.

What would FORCE do? We actually need quote control on output and null
control on input, or am I wrong? Do we have input OK with the warning
idea?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073