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

H.Merijn Brand wrote:
> On Wed, 4 Apr 2012 12:55:14 -0400, "Jens Rehsack via RT"
>> 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. 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.
> 
> I have included the devel list to see how others think

Damn right that tables/rows/etc with zero columns should be supported!

All SQL or relational databases should support zero-column tables/rows.

Those are very important to *the* relational model.

For example, with (natural) join operations (or product or intersect), the 
zero-column table is analogous to the number 1 if it has one row and to the 
number 0 if it has none; the one-row version is the identity value for join.

Or, if you define a unique/key constraint that ranges over zero columns, that is 
a simple way to restrict the table to having at most one row, which is useful 
say if you want to have a table storing singleton information.

Practically speaking, supporting zero-column tables/rows just makes sense, it 
makes as much sense as supporting Perl array or hash variables that are allowed 
to be empty, or allowing empty sets, which are identity values for set unions or 
hash/array catenation.

 From DBI's perspective, as we use Array/Hash to represent rows, it is just the 
empty one of those to represent the zero-column one.

Suffice it to say, if even one DBMS supports this, DBI should too, and this is 
an example others can follow.

-- Darren Duncan