Re: [HACKERS] Replication vs. float timestamps is a disaster
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Replication vs. float timestamps is a disaster |
Дата | |
Msg-id | 31590.1487599653@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Replication vs. float timestamps is a disaster (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Replication vs. float timestamps is a disaster
Re: [HACKERS] Replication vs. float timestamps is a disaster Re: [HACKERS] Replication vs. float timestamps is a disaster |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2017-02-20 11:58:12 +0100, Petr Jelinek wrote: >> That being said, I did wonder myself if we should just deprecate float >> timestamps as well. > I think we need a proper deprecation period for that, given that the > conversion away will be painful for pg_upgrade using people with big > clusters. So I think we should fix this regardless... :( The question to be asked is whether there is still anybody out there using float timestamps. I'm starting to get dubious about it myself. Certainly, no packager that I'm aware of has shipped a float-timestamp build since we switched the default in 8.4. Maybe there is somebody who's faithfully built a float-timestamp custom build every year so they can pg_upgrade in place from their 8.3 installation, but there have got to be darn few such people. As for "proper deprecation period", the documentation has called the option deprecated since 8.4: -disable-integer-datetimesDisable support for 64-bit integer storage for timestamps andintervals, and store datetime valuesas floating-point numbersinstead. Floating-point datetime storage was the default inPostgreSQL releases prior to 8.4,but it is now deprecated,because it does not support microsecond precision for the fullrange of timestamp values. I think the strongest reason why we didn't move to kill it sooner was that we were not then assuming that every platform had 64-bit ints; but we've required that since 9.0. regards, tom lane
В списке pgsql-hackers по дате отправления: