Re: Dropping a composite attribute causes data integrity violations

Hi Nikhil,

On Fri, Nov 13, 2026 at 4:46 PM Nikhil Sontakke
<nikhil(at)planetscale(dot)com> wrote:
> On master without the v3 patch, all of your scenarios still go through:
> N1/N2 (stored columns), S1-S6 (constants in views, CHECK, DEFAULT,
> function parameter default, table row type in a view) and both
> controls.
[...]
> With the single call from ATExecDropColumn() that v2 already added,
> all of N1, N2 and S1-S6 are now refused with specific errors

That reproduces here on master at 77bba5454f9. Without v3 all ten
scenarios in the script are accepted and REINDEX of N1's unique index
fails. With v3 the eight are refused with "cannot alter type/table ...
uses it", as are 18 more stored cases I tried. C1 is still allowed, but
C2 (NULL::c2 in a view) is now refused, as ALTER ... TYPE already is.

> Heikki and Andres, I'd like your opinion on this part.

With only the tablecmds.c change, master's alter_table (attdrop_*,
test_typex, test_tbl3), rowtypes (compositetable_drop), oldest_xmin and
009_composite_types fail. Only attdrop_*, compositetable_drop and 009
came with this month's security fixes. With v3's versions of those, a
same-version run of 009 no longer upgrades a stored value whose dropped
attribute held data, and compositetable_drop no longer drops the column
during the UPDATE.

My earlier patch is no longer needed for these cases, on master or on
REL_18_STABLE. There the ten drops also go through without v3, and v3
applies with git am and refuses the same ones.

Regards,
Manu