On Thu, May 22, 2025 at 11:51 PM Tom Lane <tgl@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-124ee808cda7@gmail.com
Thanks
Richard
