Re: cataloguing NOT NULL constraints

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: cataloguing NOT NULL constraints
Дата
Msg-id CAMsGm5cxMpNZ674k-ushBSfex6xqTW-QhL+BS-_-rQHvex1f6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: cataloguing NOT NULL constraints  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: cataloguing NOT NULL constraints
Список pgsql-hackers
On Tue, 25 Jul 2023 at 14:59, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland <isaac.morland@gmail.com> wrote:
> My suggestion is for \d+ to show NOT NULL constraints only if there is something weird going on (wrong name, duplicate constraints, …). If there is nothing weird about the constraint then explicitly listing it provides absolutely no information that is not given by "not null" in the "Nullable" column. Easier said than done I suppose. I'm just worried about my \d+ displays becoming less useful.

I mean, the problem is that if you want to ALTER TABLE .. DROP
CONSTRAINT, you need to know what the valid arguments to that command
are, and the names of these constraints will be just as valid as the
names of any other constraints.

Can't I just ALTER TABLE … DROP NOT NULL still?

OK, I suppose ALTER CONSTRAINT to change the deferrable status and validity (that is why we're doing this, right?) needs the constraint name. But the constraint name is formulaic by default, and my proposal is to suppress it only when it matches the formula, so you could just construct the constraint name using the documented formula if it's not explicitly listed.

I really don’t see it as a good use of space to add n lines to the \d+ display just to confirm that the "not null" designations in the "Nullable" column are implemented by named constraints with the expected names.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: cataloguing NOT NULL constraints
Следующее
От: Andres Freund
Дата:
Сообщение: Re: WAL Insertion Lock Improvements