Hi Nikhil, On Fri, Nov 13, 2026 at 4:46 PM Nikhil Sontakke <[email protected]> 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
