Re: Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename
От | Michael Paquier |
---|---|
Тема | Re: Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename |
Дата | |
Msg-id | CAB7nPqRQJrVsXZ_n==KUcxVHKthN5pt_FJT-fwq=+EwB1c+Auw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Dec 15, 2015 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Craig Ringer <craig@2ndquadrant.com> writes: >> Does anyone know why Form_pg_sequence has a field sequence_name that >> duplicates the sequence's name from pg_class ? > > It's historical, for sure. We won't be removing it in the foreseeable > future because of on-disk-compatibility issues. But you might want to > read the pghackers archives, five or ten years back, where we speculated > about redoing sequences to combine them all into one system catalog > (ie, store one row per sequence not one relation per). Aside from > application compatibility issues, the stumbling block seemed to be how to > separate transactional from nontransactional updates. That particular > problem is also why ALTER SEQUENCE RENAME can't update the sequence's copy > of the relation name: the wrong things happen if you roll back. That's a little bit older than 5/10 years visibly, see commit 7415105. But yes as the sequence data is stored as a single always-visible tuple on its relfilenode, there is no way to remove it without breaking on-disk compatibility, but moving back in time, it would have been surely possible to rely on the sequence OID instead. -- Michael
В списке pgsql-hackers по дате отправления: