| 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: | Whole Thread | Raw Message | 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? |