Re: Fix SET EXPRESSION for virtual columns with whole-row dependencies

On Sat, Jun 13, 2026 at 2:02 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > On Jun 13, 2026, at 10:42, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> >
> > On Wed, Jun 10, 2026 at 5:06 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >>
> >>
> >> After reading the other implementation in [1], I realized that I had missed the partial-index case, so I added coverage for that.
> >>
> >> I am still sending an updated version of this patch because my implementation is different from the one in [1]. I would like people to compare the two approaches and decide which direction is better.
> >>
> >
> > I tried your patch before but abandoned it due to many regression test failures.
> >
>
> Thanks for looking. But I wonder which tests I missed?
>
> I ran “make check-world” locally and passed. The CI tests all passed on the CF: https://commitfest.postgresql.org/patch/6867/
>

Apologies for the confusion.

I meant that I actually tried the same idea earlier, but abandoned it
after seeing many regression test failures.

Your v2 patch passes all the regression tests because of the special handling
added to the DEFAULT branch in RememberAllDependentForRebuilding. However, the
point of my previous message was that I am worried this special
handling below might
not be bulletproof (if foundObject.classId is not TypeRelationId, then
elog(ERROR) will be reached):

/*
* We don't expect any other sorts of objects to depend on a
- * column.
+ * column. A whole-relation scan can find the relation's row
+ * type, which doesn't need rebuilding for SET EXPRESSION.
*/
+ if (attnum == 0 &&
+ foundObject.classId == TypeRelationId &&
+ get_typ_typrelid(foundObject.objectId) == RelationGetRelid(rel))
+ continue;
+