Re: Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unused(?) field Form_pg_sequence.sequence_name, not updated by seq rename
Date: 2015-12-15 05:19:26
Message-ID: CAB7nPqRQJrVsXZ_n==KUcxVHKthN5pt_FJT-fwq=+EwB1c+Auw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 15, 2015 at 2:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2015-12-15 05:28:46 Re: find_inheritance_children() and ALTER TABLE NO INHERIT
Previous Message amul sul 2015-12-15 05:16:42 small query, about skipping dump in dumpAttrDef