On Tue, 14 Jul 2026 at 06:16, jian he <[email protected]> wrote: > > On Mon, May 25, 2026 at 2:43 PM jian he <[email protected]> wrote: > > > > Overall, the attached v9 doesn't include any major changes. > > It just contains some refactoring to make the coding style consistent with > > [1]. > > > > Hi. > Rebase because of > https://git.postgresql.org/cgit/postgresql.git/commit/?id=a4639d64e2199885f8e995395b6fe874cb7228bf > I also simplified the code a little bit, polished the comments, and > merged 3 patches into one, no major changes. > > Below is the commit message: > Subject: [PATCH v14 1/1] Whole-row fixes for DROP COLUMN, SET COLUMN DATA TYPE > > ALTER TABLE DROP COLUMN should remove indexes or constraints contain whole-row > references, just like non-whole-row column. > > ALTER TABLE DROP COLUMN should fail if a trigger WHEN clause or row-level > security policy contains a whole-row reference. To do this, record a > dependency > between the relation and the trigger or policy in > RememberWholeRowDependentForRebuilding; performMultipleDeletions then handles > the deletion checks. > > ALTER COLUMN SET DATA TYPE fundamentally changes the table’s record type; At > present, we cannot compare records that contain columns of dissimilar types, > see > function record_eq. As a result, ALTER COLUMN SET DATA TYPE does not work for > whole-row reference objects (such as constraints and indexes), and must > therefore raise an error.
I think the current suggested approach with scanning pg_index/pg_constraint/etc. is horrible for performance, as it uses O(total_dependent_objects) to figure out who has whole-row references, rather than just O(n_whole_row_dependencies). I think the better approach is to properly register whole-row Vars in pg_depends as their own objsubid, allowing invalidation of the dependencies whenever the whole-row definition changes. Additionally, I don't think that dropping whole-row indexes is proper when the column is dropped or changes data type; the index definition is still correct, it just needs to be rebuilt. See my fix for this class of issues at [0] (cf [1], it implements the approach I described. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com) [0]: https://www.postgresql.org/message-id/flat/CAEze2WjDaDyvztdXh3Cb2J=11cmvrp4nwaw0e6dbrka1t9w...@mail.gmail.com [1]: https://commitfest.postgresql.org/patch/7071/
