Re: ALTER TABLE ADD COLUMN fast default
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-04-05T16:10:48Z
Lists: pgsql-hackers
Attachments
- fix-adbin-inconsistencies-2.patch (text/x-diff) patch
Andrew Dunstan <andrew@dunslane.net> writes: > On 4/4/21 6:50 PM, Tom Lane wrote: >> Meh. "pg_class.relchecks is inconsistent with the number of entries >> in pg_constraint" does not seem to me like a scary enough situation >> to justify a panic response. Maybe there's an argument for failing >> at the point where we'd need to actually apply the CHECK constraints >> (similarly to what my patch is doing for missing defaults). >> But preventing the user from, say, dumping the data in the table >> seems to me to be making the situation worse not better. > OK, fair argument. Here's a v2 that applies the same principles to struct ConstrCheck as AttrDefault, ie create only valid entries (no NULL strings), and if there's not the right number, complain at point of use rather than failing the relcache load. There is a hole in this, which is that if pg_class.relchecks = 0 then we won't even look in pg_constraint, so we won't realize if there is an inconsistency. But that was true before, and I don't want to expend an almost-always-useless catalog search to see if relchecks = 0 is a lie. I also tried to bring the related message texts up to something approaching project standards, though I didn't convert them into translatable ereports. regards, tom lane
Commits
-
Clean up treatment of missing default and CHECK-constraint records.
- 091e22b2e673 14.0 landed
-
Fast ALTER TABLE ADD COLUMN with a non-NULL default
- 16828d5c0273 11.0 landed
-
Fix application of identity values in some cases
- 533c5d8bddf0 11.0 cited