| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> | 
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: cataloguing NOT NULL constraints | 
| Date: | 2023-03-15 22:44:40 | 
| Message-ID: | 20230315224440.cz3brr6323fcrxs6@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Here's v5.  I removed the business of renaming constraints in child
relations: recursing now just relies on matching column names.  Each
column has only one NOT NULL constraint; if you try to add another,
nothing happens.  All in all, this code is pretty similar to how we
handle inheritance of columns, which I think is good.
I added a mention that this funny syntax
  ALTER TABLE tab ADD CONSTRAINT NOT NULL col;
is not standard.  Maybe it's OK, but it seems a bit too prominent to me.
-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
| Attachment | Content-Type | Size | 
|---|---|---|
| v5-0001-Catalog-NOT-NULL-constraints.patch | text/x-diff | 166.5 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2023-03-16 00:03:14 | Re: Allow logical replication to copy tables in binary format | 
| Previous Message | Andrew Dunstan | 2023-03-15 22:18:28 | Re: Add a hook to allow modification of the ldapbindpasswd |