| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Suraj Kharage <suraj(dot)kharage(at)enterprisedb(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints |
| Date: | 2025-01-08 09:13:22 |
| Message-ID: | 202501080913.bs6k2rk2xc2j@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024-Nov-25, Suraj Kharage wrote:
> Another case which needs conclusion is -
> When changing from INHERIT to NO INHERIT, we need to walk all children and
> decrement coninhcount for the corresponding constraint. If a constraint in
> one child reaches zero, should we drop it? not sure. If we do, make sure
> to reset the corresponding attnotnull bit too. We could decide not to drop
> the constraint, in which case you don’t need to reset attnotnull.
I think it's more useful if we keep such a constraint (but of course
change its conislocal to true, if it isn't that already).
There are arguments for doing both things (drop it or leave it); but if
you drop it, there's no way to put it back without scanning the table
again. If you keep it, it's easy to drop it afterwards.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-01-08 09:31:11 | Re: Re: proposal: schema variables |
| Previous Message | Kashif Zeeshan | 2025-01-08 09:07:33 | Re: [PoC] Federated Authn/z with OAUTHBEARER |