Re: [rt.cpan.org #76276] support 0-column input tables?

Am 05.04.2012 09:20, schrieb [email protected] via RT:
>        Queue: DBD-CSV
>  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=76276 >
> 
> On Wed, 4 Apr 2012 12:55:14 -0400, "Jens Rehsack via RT"
> <[email protected]> wrote:
> 
>> Merjin,
> 
> By now, you'd know how not to switch the i and j, right?

*whistl*

>> can you throw it over into SQL::Statement Queue? It's reasonable to
>> handle it there.
> 
> Sure. I thought it would be DBD::File, as the *file* is empty and thus
> would do the same for all DBD::File related DBD's.

I do not expect that any DBD::* code is involved in the bug - but
probably it's an non-instantiated table. I try to create a small
test case and if I can't figure out what#s going wrong, I ask the
originator for more details ...

> It might even
> warrant a new attribute to allow this as normally in DBI a table always
> has columns (but not always rows). If a file is empty, it doesn't even
> have columns. Not all databases allow the creation of "empty" tables, as
> in a table with no rows at all. Postgres does, but Unify and Oracle do
> not.

Well, if the table is created with columns specified, you're right.
If the originator wants the columns guessed from an empty b.csv, you're
wrong from my point of view. DBD::CSV is special (as some DBD::AnyData,
too), because it "guesses" columns from data file.

Probably an $dbh attribute "f_default_columns" can help out, but before
we think further let me dig out the root cause ;)

I'm a bit busy with communion of my younger dauther until end of April
and then something to clarify with our house renter - I expect I can
invest larger blocks of time in mid of May. I hope I can create a
test case before ...

> I have included the devel list to see how others think

So did I - good suggestion.

Best,
Jens