Thread: ERROR: no NOT NULL constraint found to drop
I run into error $subject with the query below:
# create table t1 (c int primary key null unique);
CREATE TABLE
# create table t2 (like t1);
CREATE TABLE
# alter table t2 alter c drop not null;
ERROR: no NOT NULL constraint found to drop
This starts since e056c557ae. I guess this shouldn't happen since the
comment says so.
/* this shouldn't happen */
elog(ERROR, "no NOT NULL constraint found to drop");
Thanks
Richard
# create table t1 (c int primary key null unique);
CREATE TABLE
# create table t2 (like t1);
CREATE TABLE
# alter table t2 alter c drop not null;
ERROR: no NOT NULL constraint found to drop
This starts since e056c557ae. I guess this shouldn't happen since the
comment says so.
/* this shouldn't happen */
elog(ERROR, "no NOT NULL constraint found to drop");
Thanks
Richard
On Mon, Apr 10, 2023 at 03:16:06PM +0800, Richard Guo wrote: > I run into error $subject with the query below: > > # create table t1 (c int primary key null unique); > CREATE TABLE > # create table t2 (like t1); > CREATE TABLE > # alter table t2 alter c drop not null; > ERROR: no NOT NULL constraint found to drop > > This starts since e056c557ae. I guess this shouldn't happen since the > comment says so. > > /* this shouldn't happen */ > elog(ERROR, "no NOT NULL constraint found to drop"); Thanks for the report. This is not the only issue that has been pointed out with this patch, so it is going to be reverted if you look around here: https://www.postgresql.org/message-id/3863449.1681071102@sss.pgh.pa.us -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes: > On Mon, Apr 10, 2023 at 03:16:06PM +0800, Richard Guo wrote: >> I run into error $subject with the query below: >> # create table t1 (c int primary key null unique); >> CREATE TABLE >> # create table t2 (like t1); >> CREATE TABLE >> # alter table t2 alter c drop not null; >> ERROR: no NOT NULL constraint found to drop > Thanks for the report. This is not the only issue that has been > pointed out with this patch, so it is going to be reverted if you look > around here: It's still good to know about it for next time. The issue I guess is that LIKE with no options propagates column attnotnull bits, but not constraints, so we now have an inconsistency: t2.c has attnotnull set but there is nothing in pg_constraint to justify it. It seems to me we're going to have to think about what we want to happen in this case. In a green field we'd probably not propagate NOT NULL unless told to copy constraints ... but is it okay to break functional compatibility with the old behavior? regards, tom lane
On Mon, Apr 10, 2023 at 09:46:59AM -0400, Tom Lane wrote: > It's still good to know about it for next time. The issue I guess is > that LIKE with no options propagates column attnotnull bits, but not > constraints, so we now have an inconsistency: t2.c has attnotnull set > but there is nothing in pg_constraint to justify it. It seems to me > we're going to have to think about what we want to happen in this > case. In a green field we'd probably not propagate NOT NULL unless > told to copy constraints ... but is it okay to break functional > compatibility with the old behavior? I am not sure about that, TBH, though I would tend to not break compatibility just for the sake of breaking it. Anyway, shouldn't we have a test that does a DROP NOT NULL after a LIKE copies it? At least, we'll be able to track that. -- Michael