diff options
author | David Rowley <drowley@postgresql.org> | 2020-04-17 10:29:49 +1200 |
---|---|---|
committer | David Rowley <drowley@postgresql.org> | 2020-04-17 10:29:49 +1200 |
commit | 5b736e9cf95793ca6a4c00d291a06dfe3559c8ec (patch) | |
tree | 465a1bfda77ee4e736684075b79043ca12b1361d /src/backend/executor/nodeModifyTable.c | |
parent | fc576b7c4f3a5f045d443fc771d9e0f54b33e72b (diff) | |
download | postgresql-5b736e9cf95793ca6a4c00d291a06dfe3559c8ec.tar.gz postgresql-5b736e9cf95793ca6a4c00d291a06dfe3559c8ec.zip |
Remove unneeded constraint dependency tracking
It was previously thought that remove_useless_groupby_columns() needed to
keep track of which constraints the generated plan depended upon, however,
this is unnecessary. The confusion likely arose regarding this because of
check_functional_grouping(), which does need to track the dependency to
ensure VIEWs with columns which are functionally dependant on the GROUP BY
remain so. For remove_useless_groupby_columns(), cached plans will just
become invalidated when the primary key's underlying index is removed
through the normal relcache invalidation code.
Here we just remove the unneeded code which records the dependency and
updates the comments. The previous comments claimed that we could not use
UNIQUE constraints for the same optimization due to lack of a
pg_constraint record for NOT NULL constraints (which are required because
NULLs can be duplicated in a unique index). Since we don't actually need a
pg_constraint record to handle the invalidation, it looks like we could
add code to do this in the future. But not today.
We're not really fixing any bug in the code here, this fix is just to set
the record straight on UNIQUE constraints. This code was added back in
9.6, but due to lack of any bug, we'll not be backpatching this.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAApHDvrdYa=VhOoMe4ZZjZ-G4ALnD-xuAeUNCRTL+PYMVN8OnQ@mail.gmail.com
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions