The way I've generally handled initialization of timestamps and dates is
through string conversions functions. For example, a (native) Falcon
table could be created like:
create table t (when_stored timestamp default 'now');
The Falcon (and Firebird and Interbase and Rdb) string to date functions
all recognize the string "now" to mean the current time. Also
recognized by the string to date function are the strings:
"today"
"tomorrow"
"yesterday"
but not
"next Thursday"
"never"
"Ann's Birthday" (this almost made the cut)
Falcon (and Nimbus) also recognize
"thismonth"
"thisday"
"thisyear"
each of which can be added or subtracted from. This leaves room for all
sorts of cute tricks like:
thisday, thismonth + 1 (January 19) [today is December 19]
1, thismonth (December 1)
0, thismonth (November 30)
Treating "today" and "now" as strings rather than manifest constants is
non-traditional, but very powerful, well-defined, and upwards compatible
from about anything and everything. Adopting this strategy would get
you out of the horrible timestamp magic currently in the server.
This technique could easily be extended for initialization of UUIDs and
(with a little bit more work) autoincrement fields. Personally, I would
be more inclined to punt on autoincrement in favor of legitimate
sequences, referenced with something like "initial value 'increment
generator xyz'". That, however, is a separate issue for discussion.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
