On Tue, 14 Jul 2026 at 06:16, jian he <jian.universality@gmail.com> wrote:
>
> On Mon, May 25, 2026 at 2:43 PM jian he <jian.universality@gmail.com> 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=11CMVRp4NWAW0E6dBRKa1T9w5ag@mail.gmail.com
[1]: https://commitfest.postgresql.org/patch/7071/
