Re: [PATCH] Rebuild CHECK constraints after generated column SET EXPRESSION

On Wed, 22 Jul 2026 at 18:15, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 15.07.26 17:44, Nathan Bossart wrote:
> > [RMT hat]
> >
> > On Wed, Jul 08, 2026 at 08:15:54PM +0200, Peter Eisentraut wrote:
> >> Committed with some code beautification editorialization.
> >
> > This is listed on the v19 open items wiki [0] as an "older bug affecting
> > stable branches." Is there more work to do, or can this be moved to the
> > "fixed issues" section?
> >
> > [0] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
>
> This is a fix for new-in-PG19 functionality, so I think that
> classification is wrong.

I think this addressed just one symptom of the issue where PostgreSQL
doesn't track whole-row expressions as a relevant dependency type, and
so fails (failed) to invalidate whole-row Var -dependent objects. Yes,
it was a new facet of the issue, but the issue itself was not new in
PG19: Every catalog object type that relies on pull_varattnos() to
track which columns are referenced is going to hit this issue; and no
current path (other than SET EXPRESSION now) causes indexes and
constraints to get rebuilt when the whole-row var expression changes
meaning.

I'd also say that the way SET EXPRESSION fixes this is ... suboptimal.
RememberWholeRowDependentForRebuilding considers *all* indexes and
constraints on the relation for invalidation, rather than just the
ones that contain whole-row Vars. In partitioned systems, that can
mean touching a huge number of catalogs just to check that there are
no relevant CHECK constraints nor expression indexes.

See [0] for my patch that solves this in a more holistic approach, by
explicitly tracking whole-row Vars, and using that tracking to find
and only consider the whole-row Var -referencing objects in
RememberWholeRowDependentForRebuilding.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

[0]: https://postgr.es/m/CAEze2WjDaDyvztdXh3Cb2J=11CMVRp4NWAW0E6dBRKa1T9w5ag@mail.gmail.com