Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object

On Mon, Sep 15, 2025 at 11:48 AM Chao Li <li.evan.chao@gmail.com> wrote:
>
> 3 - 0001
> ```
> + }
> + }
> + ReleaseSysCache(indexTuple);
> + }
> + CommandCounterIncrement();
> ```
>
> Why CommandCounterIncrement() is needed? In current code, there is a CommandCounterIncrement() after CatalogTupleUpdate(), which is necessary. But for your new code, maybe you considered “recordDependencyOn()” needs CommandCounterIncrement(). I searched over all places when “recordDependencyOn()” is called, I don’t see CommandCounterIncrement() is called.
>
My thought is that CommandCounterIncrement may be needed;
because recordDependencyOn inserts many tuples to pg_depend,
then later performMultipleDeletions will interact with pg_depend.


>
> 5 - 0001
> ···
> + conscan = systable_beginscan(conDesc, ConstraintRelidTypidNameIndexId, true,
> + NULL, 3, skey);
> + if (!HeapTupleIsValid(contuple = systable_getnext(conscan)))
> + elog(ERROR, "constraint \"%s\" of relation \"%s\" does not exist",
> + constr_name, RelationGetRelationName(rel));
> ···
>
> Should we continue after elog()?
>
if "elog(ERROR," happens, then it will abort, so there is no need to
"continue", I think.

Summary of attached v4:
v4-0001: Handles ALTER TABLE DROP COLUMN when whole-row Vars are
referenced in check constraints and indexes.

v4-0002: Handles ALTER TABLE ALTER COLUMN SET DATA TYPE when whole-row
Vars are referenced in check constraints and indexes.

v4-0003: Handle ALTER TABLE ALTER COLUMN SET DATA TYPE and ALTER TABLE DROP
COLUMN when policy objects reference whole-row Vars.  Policy quals and check
quals may contain whole-row Vars and can include sublinks (unplanned
subqueries), pull_varattnos is not enough to locate whole-row Var. Instead,
obtain the whole-row type OID and recursively check each Var in expression node
to see if its vartype matches the whole-row type OID.