Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
От | Mark Dilger |
---|---|
Тема | Re: [HACKERS] Something for the TODO list: deprecating abstime and friends |
Дата | |
Msg-id | 3CD79F5D-DB73-4F2A-B698-44FF1930CB97@gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Something for the TODO list: deprecating abstime and friends (Mark Dilger <hornschnorter@gmail.com>) |
Ответы |
Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
|
Список | pgsql-hackers |
> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote: > > >> On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> The types abstime, reltime, and tinterval need to go away, or be >> reimplemented, sometime well before 2038 when they will overflow. >> It's not too soon to start having a plan for that, especially seeing >> that it seems to take a decade or more for us to actually get rid >> of anything we've deprecated. >> >> Right offhand, I don't think there is any functionality in these >> types that isn't handled as well or better by timestamptz, interval, >> and tstzrange respectively. > > These types provide a 4-byte datatype for storing real-world second > precision timestamps, as occur in many log files. Forcing people to > switch to timestamp or timestamptz will incur a 4 byte per row > penalty. In my own builds, I have changed the epoch on these so > they won't wrap until sometime after 2100 C.E. I see little point in > switching to an 8-byte millisecond precision datatype when a perfectly > good 4-byte second precision datatype already serves the purpose. > > That said, I am fully aware that these are deprecated and expect you > will remove them, at which time I'll have to keep them in my tree > and politely refuse to merge in your change which removes them. Oh, and if you could be so kind, please remove them in a commit that does nothing else. It's much easier to skip the commit that way. Thanks! mark
В списке pgsql-hackers по дате отправления: