Re: Virtual generated columns

On Tue, 18 Feb 2025 at 13:12, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>
> > It seems to me that, for a relation in the rangetable that has virtual
> > generated columns, we can consider it a subquery to some extent. For
> > instance, suppose we have a query:
> >
> > select ... from ... join t on ...;
> >
> > and suppose t.b is a virtual generated column. We can consider this
> > query as:
> >
> > select ... from ... join (select a, expr() as b from t) as t on ...;
> >
> > In this sense, I'm wondering if we can leverage the
> > pullup_replace_vars architecture to expand the virtual generated
> > columns. I believe this would help avoid a lot of duplicate code with
> > pullup_replace_vars_callback.

Yes, I think this is much better. Having just one place that does that
complex logic is a definite win.

At one point I had the idea of making the rewriter turn RTEs with
virtual generated columns into subquery RTEs, so then the planner
would treat them just like views, but that would have been less
efficient. Also, I think there would have been a problem with RLS
quals, which would have been added to the subquery RTEs. Perhaps that
could have been fixed up during subquery pullup, but it felt ugly and
I didn't actually try it.

> I had a try with this idea, and attached is what I came up with. It
> fixes all the mentioned issues but still requires significant
> refinement, particularly due to the lack of comments. By leveraging
> the pullup_replace_vars architecture to expand the virtual generated
> columns, it saves a lot of duplicate code.

One thing I don't like about this is that it's introducing more code
duplication between pullup_replace_vars() and
ReplaceVarsFromTargetList(). Those already had a lot of code in common
before RETURNING OLD/NEW was added, and this is duplicating even more
code. I think it'd be better to refactor so that they share common
code, since it has become quite complex, and it would be better to
have just one place to maintain. Attached is an updated patch doing
that.

Regards,
Dean