On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote: > As a result, I have a few questions about the timestamp code. In what > instances is the floating point timestamp recommended?
One circumstance is when there isn't a native int64 type available. The floating point datetime code is the traditional implementation -- until recently the integer datetime code was less tested and more buggy, although I don't think that is still the case. For 8.4 I'm planning to submit a patch to make integer datetimes the default, per earlier discussion. > Is the backend smart enough to not load and use a database with > timestamp fields created with the representation not compiled into the > compiler? Postgres will refuse to start if the compiled-in datetime representation doesn't match the datetime representation used by the specified data directory. > And finally, would this work be welcome in PostgreSQL? Yes, sounds like a useful improvement to me. There are quite a few cleanups and refactorings that could be done to the datetime code. -Neil ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match