aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_utilcmd.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2024-04-15 12:20:56 +0200
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2024-04-15 12:20:56 +0200
commitc3709100be73ad5af7ff536476d4d713bca41b1a (patch)
tree2ba97aabd1032278ea4535d49627ddcf54a0e67d /src/backend/parser/parse_utilcmd.c
parent6ff21c05302592874b8149421711e06043b954fe (diff)
downloadpostgresql-c3709100be73ad5af7ff536476d4d713bca41b1a.tar.gz
postgresql-c3709100be73ad5af7ff536476d4d713bca41b1a.zip
Fix propagating attnotnull in multiple inheritance
In one of the many strange corner cases of multiple inheritance being used, commit b0e96f311985 missed a CommandCounterIncrement() call after updating the attnotnull flag during ALTER TABLE ADD COLUMN, which caused a catalog tuple to be update attempted twice in the same command, giving rise to a "tuple already updated by self" error. Add the missing call to solve that, and a test case that reproduces the scenario. As a (perhaps surprising) secondary effect, this CCI addition triggers another behavior change: when a primary key is added to a parent partitioned table and the column in an existing partition does not have a not-null constraint, we no longer error out. This will probably be a welcome change by some users, and I think it's unlikely that anybody will miss the old behavior. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: http://postgr.es/m/045dec3f-9b3d-aa44-0c99-85f6992306c7@gmail.com
Diffstat (limited to 'src/backend/parser/parse_utilcmd.c')
0 files changed, 0 insertions, 0 deletions