> Can I assume that this as well as the text->varchar will be fixed in
> 6.4?
text->varchar is likely to be addressed (as well as other string issues
such as ensuring correct maximum length in target columns).
> adserver=> select NOW()::DATETIME::TIMESTAMP;
> ERROR: function datetime_stamp(datetime) does not exist
Hmm. I wrote most of the routines you might want to go _to_ datetime,
but did not fully populate the functions to go _away_ from datetime. For
timestamp in particular, I didn't want to spend the time, since I was
planning on replacing timestamp with datetime sometime soon.
However, I haven't taken that step yet because:
1) I think that the current datetime implementation makes more sense
than the SQL92 specification for timestamp (of course, I wrote it so I'm
a bit biased :)
2) imho implementing _full_ SQL92 timestamp behavior is a waste of time
(damaged functionality wrt datetime and bizarre syntax, usage, and
behavior, among other reasons).
3) others may have a strong opinion that a _full_ SQL92 timestamp is
important (I would hope that they have a real need for it, rather than
it being a "well, it should" argument because afaik no one actually uses
the most arcane SQL92 features of timestamp, since they make little
sense).
4) I'm not likely to be willing to support a damaged form of
datetime/timestamp at the expense of a full-featured datetime, but the
project might decide to head that direction.
My feeling is that the SQL92 form of timestamp is a mish-mash of
requirements and features to accomodate existing database products.
Starting from scratch, no one would have come close to the SQL92
standard for this. The datetime type is more in keeping with how date
and time actually behave, and is what timestamp should be.
Anyway, a discussion of this may be in order. Anyone??
- Tom
