Front page | perl.dbi.dev |
Postings from April 2012
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 DuncanThread Previous | Thread Next