]> granicus.if.org Git - postgresql/commit
Apply ALTER ... SET NOT NULL recursively in ALTER ... ADD PRIMARY KEY.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 4 Aug 2017 15:45:18 +0000 (11:45 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 4 Aug 2017 15:45:18 +0000 (11:45 -0400)
commitc30f1770a93db1492755934048656ea809c1f569
treec3bf03153aaa6e87f4d1a3cec36e093ac28ba1d3
parent97d3a0b0900a30fc51823c2d806ab621299f1b07
Apply ALTER ... SET NOT NULL recursively in ALTER ... ADD PRIMARY KEY.

If you do ALTER COLUMN SET NOT NULL against an inheritance parent table,
it will recurse to mark all the child columns as NOT NULL as well.  This
is necessary for consistency: if the column is labeled NOT NULL then
reading it should never produce nulls.

However, that didn't happen in the case where ALTER ... ADD PRIMARY KEY
marks a target column NOT NULL that wasn't before.  That was questionable
from the beginning, and now Tushar Ahuja points out that it can lead to
dump/restore failures in some cases.  So let's make that case recurse too.

Although this is meant to fix a bug, it's enough of a behavioral change
that I'm pretty hesitant to back-patch, especially in view of the lack
of similar field complaints.  It doesn't seem to be too late to put it
into v10 though.

Michael Paquier, editorialized on slightly by me

Discussion: https://postgr.es/m/b8794d6a-38f0-9d7c-ad4b-e85adf860fc9@enterprisedb.com
src/backend/catalog/index.c
src/test/regress/expected/alter_table.out