Paolo, > Is there a performance reason, future (un)support, cleaniness, ... > to switch from "time_iso char(16) NOT NULL," > to "time_iso TIMESTAMP NOT NULL DEFAULT 0," ??
> I can't see a good reason, except for a more understandable DB > maintenance query. Yes, that is one. The other is that with PostgreSQL it is hard to deal with Unix numeric timestamps but easy with with TIMESTAMPs, so we provide both: the numeric and an ASCII representation and let admins decide which they like best. Gary V writes: > My impression is ... that msgs.time_iso was originally > created with the assumption that a field like that may be used at some > time in the future and it would be better to have it and not need it > than to need it and not have it. > It looks like PostgreSQL later took advantage of its existence. Right on both accounts. > I think time_iso char(16) > is not really of much use and ends up being a a kind of placeholder. It can still be used as a sort key, if one wants, and manually specifying a date/time (e.g. in a SELECT) is still an option, if some database can not do better. Time calculations may not be available, but other that that the char(16) may still be useful as a last resort, or to include it in reports. > I would guess that indexing > on both would not be a benefit so I'm guessing you would index on one > or the other, and set up your scripts to use the one you choose to index. Right. Mark ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
