On Thu, May 22, 2025 at 11:51 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I wonder if a better answer would be to make the rewriter responsible > for this. If you hold your head at the correct angle, a table with > virtual generated columns looks a good deal like a view, and we don't > ask the planner to handle those.
In Peter's initial commit (83ea6c540), it was the rewriter that was responsible for expanding virtual generated columns. However, this approach introduced several problems (see the reports starting from [1]). In some cases, we can't simply replace Var nodes that reference virtual columns with their corresponding generation expressions. To preserve correctness, we may need to wrap those expressions in PlaceHolderVars — for example, when the Vars come from the nullable side of an outer join or are used in grouping sets. So in commit 1e4351af3, Dean and I proposed moving the expansion of virtual generated columns into the planner, so that we can insert PlaceHolderVars when needed. Yeah, the extra table_open call is annoying. In this patchset, we're performing some additional tasks while the relation is open — such as retrieving relhassubclass and attnotnull information. We also get rid of the has_subclass() call along the way. Maybe this would help justify the added cost? [1] https://postgr.es/m/75eb1a6f-d59f-42e6-8a78-124ee808c...@gmail.com Thanks Richard
