do something else with CSV loading--it sucks

[drewbanin]

option 1: maybe an ENV function like load_csv_file(...)?

option 2: force the user to write the model as follows (this is terrible pseudocode):

{ for item in dict(whatever)
  return (build a concatenated select statement with a UNION ALL at the end)
}

option 3: other stuff?

option 4: kill the feature?

right now we have a fairly strong assumption that dbt does not load data into your warehouse. this feature in its current form defies that. I'd really prefer to re-implement it in a more "dbt-y" way. option 2 feels the most appropriate to me, although forcing the user to write this code is terrible. if we built a wrapper function that essentially did exactly this, then turned CSVs into an appropriate way to load configuration data, then we're getting to a place that feels more like a good solution to this, however. it would allow the user to materialize this model however they chose to.

[jthandy]

@drewbanin did a bit more thinking here. would appreciate your thoughts on the "option 2" I presented above and my commentary on why I liked it.

[drewbanin]

dbt seed is in a much better place now than it once one. In the future, we should consider other configuration options for csv files like custom schemas, sort/dist keys on Redshift, etc.

We can create new features for those issues when they come up! For now though, closing: #618