From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <thomas(at)fourpalms(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Time for 7.2.1? |
Date: | 2002-03-15 19:44:33 |
Message-ID: | 1298.1016221473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <thomas(at)fourpalms(dot)org> writes:
> It is somewhat complicated by the fact that my code tree is pretty
> massively changed in this area as I implement an int64-based date/time
> storage alternative to the float64 scheme we use now. The alternative
> would be enabled with something like #ifdef HAVE_INT64_TIMESTAMP.
> Benefits would include having a predictable precision behavior for all
> allowed dates and times.
Interesting. But if this is just an #ifdef, I can see some serious
problems coming up the first time someone runs a backend compiled with
one set of timestamp code in a database created with the other. May
I suggest that the timestamp representation be identified in a field
added to pg_control? That's how we deal with other options that
affect database contents ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-03-15 19:45:01 | Re: insert statements |
Previous Message | Jan Wieck | 2002-03-15 19:18:34 | Re: Client/Server compression? |