Hi!
So what, we switch to the standard time a datetime like Roy mentioned?
The sugar semantics around TIMESTAMP we can just make generic if we
want to.
Cheers,
-Brian
On Dec 23, 2008, at 5:23 PM, Baron Schwartz wrote:
Storage size. Don't shock people with a bigger storage size. Don't
remove the option to store less precision with smaller storage. If
you only give the one option, people who need less precision will be
unhappy about the storage size penalty, exactly the same way people
who right now want to store higher precision are unhappy.
Also, who knows what apps actually DO rely on the current precision
that would break if the thing suddenly got more precise. Instead of
something like
"timestamp is now higher precision and twice as big. If you want the
old storage size and less precision, use littletimestamp"
(argh, argh, argh, I must change everything in my app, and now I need
different codebases to be mysql/drizzle compatible!) do this:
"there's a new storage type, microtimestamp, with microsecond
precision, but it's bigger."
(hooray, nothing changes!)
On Tue, Dec 23, 2008 at 4:59 PM, Brian Aker <[email protected]> wrote:
Does making it more precise create an issue?
On Dec 23, 2008, at 1:39 PM, Baron Schwartz wrote:
2) What do people think about adding microsecond to the TIMESTAMP
data
type
by default? This would require 4 more bytes of storage per row.
timestamp with second precision is still useful. Make a new storage
type, call it MICROTIMESTAMP or something like that. Don't break
existing behavior.
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
