in reply to Re^2: Text::CSV_XS - proposed new interface
in thread Text::CSV_XS - proposed new interface

> Where do the column names come from? Good question! My thought was that if the user specifies a comma-separated columns attribute in the new() flags, those will be the column names and the first row of the file will be treated as data but that if none is supplied, the first row of data will be treated as the column names.
Think about this part very carefully. There are continual problems with DBD::CSV, because the column descriptions that work well in spreadsheets don't map directly to valid SQL column names. "Profit & Loss" works in a spreadsheet, but has to become something like "PROFIT_AND_LOSS" in a database.

By the way, allowing embedded EOLs by default sounds good. It would also be good to allow extended characters by default. The first thing I tell everyone about Text::CSV_XS is that they need to turn "binary" on...

  • Comment on Re^3: Text::CSV_XS - proposed new interface

Replies are listed 'Best First'.
Re^4: Text::CSV_XS - proposed new interface
by jZed (Prior) on Dec 18, 2004 at 17:07 UTC
    > There are continual problems with DBD::CSV, because the
    > column descriptions that work well in spreadsheets don't
    > map directly to valid SQL column names.

    Text::CSV_XS won't care about valid SQL names, that part is added by DBD::CSV and is easily handled. From the DBD::CSV pod:

    "you can supply an array ref of column names with the col_names attribute."

    > It would also be good to allow extended characters by
    > default.

    Yes, that will be the case.

[reply]

In Section Meditations