Re: cataloguing NOT NULL constraints

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

I'm not really thrilled with the idea of every not-null constraint
having a name, to be honest. Of all the kinds of constraints that we
have in the system, NOT NULL constraints are probably the ones where
naming them is least likely to be interesting, because they don't
really have any interesting properties. A CHECK constraint has an
expression; a foreign key constraint has columns that it applies to on
each side plus the identity of the table and opclass information, but
a NOT NULL constraint seems like it can never have any property other
than which column. So it sort of seems like a waste to name it. But if
we want it catalogued then we don't really have an option, so I
suppose we just have to accept a bit of clutter as the price of doing
business.

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? Maybe even something like pg_not_null_[relname]_[attname] (with some escaping), using the pg_ prefix to make the name reserved similar to schemas and tables? And then don't show such constraints in \d, not even \d+ - just indicate it in the Nullable column of the column listing as done now. Show a NOT NULL constraint if there is something odd about it - for example, if it gets renamed, or not renamed when the table is renamed.

Sorry for the noise if this has already been decided otherwise.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation on concurrent COPY into a single relation in PG16.