"ENORMOUS" in terms of memory overhead? It depends on the context, I guess. If you don't make something required, then no one can use the parse_*() and format_*() functions in DBI unless they first explicitly register column type handlers for each DBD. That's a pain. I'd rather see DateTime be the default, but have it not loaded at all if something else is specified.
(If I am teaching you to suck eggs, ignore me)
I would have to disagree. We assume to much about what people want, or need[0]. I am always accused of this so always try to avoid it. If we where to work on the princlple of "opt out" we would have a grossly overweight DBI.
If we take my case as an example:
I have never had any need for more than trivial date handling so I certainly wouldn't want it added as default (god forbid). In no unceratain terms, handling dates is a non trivial matter, it never ceases to amaze me at how many ways I find dates represented when working in different repositories.
The only way I could see something like this added is if a good majority of databases' supported a common time-stamp simlar to "EPOCH" but, this is not about to happen and even if it did the representation of intervals etc would need to be standardised as well. Even where databases impliment "EPOCH" they then go on to use various types to represent of interval in various formats blah blah.
As far as I can see, for the DBI to provide some common routines (API) then it must must expect at least some commonality from the underlying drivers and as far as dates are concerned I am unaware of a commmon thread in this case.
> Example:
use DBI;
# Loads DateTime::Format::DBI by default
use DBI::ColumnTypes 'dates';
# DateTime::Format::Pg will be loaded on-demand by DateTime::Format::DBI use DBD::Pg;
or
# Light-weight use DBI;
# Loads the fictional Time::Piece::Format::DBI use DBI::ColumnTypes (dates => 'Time::Piece::DBI');
# The fictional Time::Piece::::Pg will be loaded on-demand use DBD::Pg;
There may need to be trivial wrappers around DateTime::Format::* to fit whatever API DBI comes up with for parsing/formatting column types, but the idea is the same.
No date parsing/formatting modules are loaded at all unless there is at least one "registration" or use() statement of DBI::ColumnTypes (or whatever the class is called). In the absence of a specific class for the "dates" umbrella column type, the DateTime modules are loaded. That doesn't mean all those DateTime modules are "required", just that people who want this functionality will have to have *some* sort of appropriate modules loaded.
I am sorry if I am reading things incorrectly.
Do you want the DBI to load default date handling facilities unless otherwise instructed ie.(load some other handlers).
Harry
[0] Where there is any ambiguity I like to work on the principle that to "opt in" is better than to "opt out". Think maling lists.
