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
