On Mon, 2026-09-21 at 01:39 -0300, Manuel Reyes Bravo wrote:
> 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
Thanks.
I briefly looked at the patch, and I wondered if you omitted
pg_partitioned_table.partexprs on purpose.
But taking a step back, I wonder if all that is worth the effort.
PostgreSQL expects data types to be immutable, so if you modify a
composite type that is used anywhere in a persistent fashion, things
will break all over the place. I doubt that we can ever plug all the
holes.
I think it is a bad idea to use composite types in table definitions
or anything else that is persistent, but we can hardly go back on
that. Perhaps we should just forbid ALTER TYPE ... ADD/DROP/ALTER?
That would be an incompatibility, but it wouldn't break upgrade.
Yours,
Laurenz Albe
