Re: not null constraints, again
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: "Tender Wang" <tndrwang@gmail.com>, Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "jian he" <jian.universality@gmail.com>,
"Pg Hackers" <pgsql-hackers@lists.postgresql.org>,
"Tom Lane" <tgl@sss.pgh.pa.us>
Date: 2025-04-17T18:17:10Z
Lists: pgsql-hackers
Hello, On Thu, Apr 17, 2025, at 7:01 PM, Tender Wang wrote: > create table t1(a int not null); > ALTER TABLE t1 ADD CONSTRAINT d PRIMARY KEY(a), ALTER a DROP NOT NULL; > > in v17.4, ALTER TABLE successes, but in v18, it reports below error: > ERROR: primary key column "a" is not marked NOT NULL Yeah, I suppose this behavior is more or less expected. ALTER TABLE subcommands are reordered for execution on several passes (per AlterTablePass, which you're already familiar with). DROP commands are always executed first, so I suppose that what happens is that we first drop the not-null (and not queue addition of one because it already exists), then when time comes to add the PK we find (index_check_primary_key) that the column isn't not null. I guess if you don't want to get this error, just don't run this command. It's quite useless anyway. Note that if the column isn't not-null to start with, then this doesn't fail, yet you still end up with the column marked not-null. -- Álvaro Herrera
Commits
-
Suppress "may be used uninitialized" warnings from older compilers.
- fc5e966f73f0 18.0 landed
-
Elide not-null constraint checks on child tables during PK creation
- 11ff192b5bb7 18.0 landed
-
Remove unnecessary code to handle CONSTR_NOTNULL
- 5b291d1c9c09 18.0 landed
-
Silence compilers about extractNotNullColumn()
- ff239c3bf4e8 18.0 landed
-
Add pg_constraint rows for not-null constraints
- 14e87ffa5c54 18.0 landed