Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Something for the TODO list: deprecating abstime and friends |
Дата | |
Msg-id | CA+TgmoY3gPi000nWof_bSQ+W6ds46D1_pcfJKWRivt6jRd9_jA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Something for the TODO list: deprecating abstime and friends (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
|
Список | pgsql-hackers |
On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I'd definitely be on board with just dropping the type altogether despite >>> Mark's concern. > >> Then I vote for that option. > > BTW, another possible compromise is to move abstime into a contrib > module; we've always accepted that contrib modules can be held to a > lower standard than core features. I'm not volunteering to do the > work for that, but it's worth contemplating. I would be OK with that, provided the documentation calls out the hazard. > Alternatively, we could turn the origin point for abstime into > pg_control field, and regard changing it as a reason for a database > not being pg_upgrade'able unless it lacks any abstime columns. I would be OK with that, too, but is there any danger that we're going to grow pg_control to a size where reads and writes can no longer be assumed atomic, if we keep adding things? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: