Re: unlogged sequences

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: unlogged sequences
Дата
Msg-id CAKFQuwa8qnzNQ_pzk19kvf3983j0N1r=OL2S2NzbuvjwHFXgjg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unlogged sequences  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: unlogged sequences  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Mar 31, 2022 at 5:25 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 31, 2022 at 10:14 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> * When linking a sequence to a table (ALTER SEQUENCE ... OWNED BY),
> there's an ereport(ERROR) if the relpersistence values do not match.
>
> * Disallow changing persistence for owned sequences directly.

Wait, what? I don't understand why we would want to do either of these things.

It seems to me that it's totally fine to use a logged table with an
unlogged sequence, or an unlogged table with a logged sequence, or any
of the other combinations. You get what you ask for, so make sure to
ask for what you want. And that's it.

It seems reasonable to extend the definition of "ownership of a sequence" in this way.  We always let you create unowned sequences with whatever persistence you like if you need flexibility.

The "give the user power" argument is also valid.  But since they already have power through unowned sequences, having the owned sequences more narrowly defined doesn't detract from usability, and in many ways enhances it by further reinforcing the fact that the sequence internally used when you say "GENERATED ALWAYS AS IDENTITY" is an implementation detail - one that has the same persistence as the table.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: unlogged sequences
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [WIP] ALTER COLUMN IF EXISTS