Re: cataloguing NOT NULL constraints

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: cataloguing NOT NULL constraints
Дата
Msg-id CAMsGm5f0iCKb9RczXJ04jGS0L3ue--C_Z21WbD5u4DR4wawQOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: cataloguing NOT NULL constraints  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: cataloguing NOT NULL constraints
Список pgsql-hackers
On Tue, 25 Jul 2023 at 12:24, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2023-Jul-25, Isaac Morland wrote:

> I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> cluttering up displays. Can we legislate that all NOT NULL implementing
> constraints are named by mashing together the table name, column name, and
> something to identify it as a NOT NULL constraint?

All constraints are named like that already, and NOT NULL constraints
just inherited the same idea.  The names are <table>_<column>_not_null
for NOT NULL constraints.  pg_dump goes great lengths to avoid printing
constraint names when they have this pattern.

OK, this is helpful. Can \d do the same thing? I use a lot of NOT NULL constraints and I very seriously do not want \d (including \d+) to have an extra line for almost every column. It's just noise, and while my screen is large, it's still not infinite.

I do not want these constraint names cluttering the output either.
That's why I propose moving them to a new \d++ command, where they will
only bother you if you absolutely need them.  But so far I have only one
vote supporting that idea.

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.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Inefficiency in parallel pg_restore with many tables