| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: cataloguing NOT NULL constraints |
| Date: | 2023-07-25 18:59:23 |
| Message-ID: | CA+TgmoaFLgpVHzDGeY=9gSk1qxK-mf-r3QRdC22eBzzShJ5uCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland <isaac(dot)morland(at)gmail(dot)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.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Isaac Morland | 2023-07-25 19:06:52 | Re: cataloguing NOT NULL constraints |
| Previous Message | Nathan Bossart | 2023-07-25 18:53:36 | Re: Inefficiency in parallel pg_restore with many tables |