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

From Isaac Morland
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id CAMsGm5cxMpNZ674k-ushBSfex6xqTW-QhL+BS-_-rQHvex1f6A@mail.gmail.com
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: cataloguing NOT NULL constraints
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: cataloguing NOT NULL constraints
Next
From: Andres Freund
Date:
Subject: Re: WAL Insertion Lock Improvements