Hi,
Attached is v2 of the patch that refuses ALTER COLUMN TYPE when a
stored expression holds a constant of the row type.
It fixes the wording for stand-alone composite types. v1 reported
ALTER TYPE t ALTER ATTRIBUTE b TYPE varchar;
ERROR: cannot alter table "t" because rule _RETURN on view v
stores a constant of its row type
where the existing column checks in find_composite_type_dependencies()
correctly say "cannot alter type". Both of the new reporting sites now
go through one helper that follows those checks (type, foreign table or
table), and the index case names the object the same way as the others
("index at_tab2_idx" instead of 'an expression of "at_tab2_idx"').
A regression test for the composite type case is added; it fails with
v1. make check passes.
I found it while reviewing Nikhil's patch in "Dropping a composite
attribute causes data integrity violations" [1], which makes ALTER TYPE
... DROP ATTRIBUTE and ALTER TABLE ... DROP COLUMN call
find_composite_type_dependencies() as well. The two patches compose:
with both, a drop is also refused when a stored constant of the row
type would change its meaning. The details are in that thread.
[1] https://postgr.es/m/CA+UBoq0F2ua2fQEAU3-6w0oxOgFc9BgEN4gRcchiUUZ+WouVrQ@mail.gmail.com
Regards,
Manu