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 по дате отправления:

Предыдущее
От: amul sul
Дата:
Сообщение: small query, about skipping dump in dumpAttrDef
Следующее
От: Amit Langote
Дата:
Сообщение: Re: find_inheritance_children() and ALTER TABLE NO INHERIT