From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unlogged sequences |
Date: | 2022-04-01 16:31:26 |
Message-ID: | c2b7ad79-e040-ebb0-b342-66eede971ef4@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01.04.22 18:22, Peter Eisentraut wrote:
>
> On 01.04.22 00:43, Tomas Vondra wrote:
>> Hmm, so what about doing a little bit different thing:
>>
>> 1) owned sequences inherit persistence of the table by default
>>
>> 2) allow ALTER SEQUENCE to change persistence for all sequences (no
>> restriction for owned sequences)
>>
>> 3) ALTER TABLE ... SET [UN]LOGGED changes persistence for sequences
>> matching the initial table persistence
>
> Consider that an identity sequence creates an "internal" dependency and
> a serial sequence creates an "auto" dependency.
>
> An "internal" dependency means that the internal object shouldn't really
> be operated on directly. (In some cases it's allowed for convenience.)
> So I think in that case the sequence must follow the table's persistence
> in all cases. This is accomplished by setting the initial persistence
> to the table's, making ALTER TABLE propagate persistence changes, and
> prohibiting direct ALTER SEQUENCE SET.
But to make pg_upgrade work for identity sequences of unlogged tables,
we need to allow ALTER SEQUENCE ... SET LOGGED on such sequences. Which
I guess is not a real problem in the end.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-04-01 16:33:34 | Re: unlogged sequences |
Previous Message | Peter Eisentraut | 2022-04-01 16:22:38 | Re: unlogged sequences |