Re: cataloguing NOT NULL constraints - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id CAMsGm5f0iCKb9RczXJ04jGS0L3ue--C_Z21WbD5u4DR4wawQOQ@mail.gmail.com
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: cataloguing NOT NULL constraints
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Logical walsenders don't process XLOG_CHECKPOINT_SHUTDOWN
Next
From: Nathan Bossart
Date:
Subject: Re: Inefficiency in parallel pg_restore with many tables