diff options
| author | Tom Lane | 2017-08-04 15:45:18 +0000 |
|---|---|---|
| committer | Tom Lane | 2017-08-04 15:45:18 +0000 |
| commit | c30f1770a93db1492755934048656ea809c1f569 (patch) | |
| tree | c3bf03153aaa6e87f4d1a3cec36e093ac28ba1d3 /doc/src | |
| parent | 97d3a0b0900a30fc51823c2d806ab621299f1b07 (diff) | |
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
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions