Re: Virtual generated columns
От | Zhang Mingli |
---|---|
Тема | Re: Virtual generated columns |
Дата | |
Msg-id | 8d6a3d4c-f630-4cf9-aced-6cead95776e5@Spark обсуждение исходный текст |
Ответ на | Virtual generated columns (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Virtual generated columns
|
Список | pgsql-hackers |
On Feb 9, 2025 at 16:00 +0800, Alexander Lakhin <exclusion@gmail.com>, wrote:
Please look at a planner error with a virtual generated column triggered
by the following script:
CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a * 1));
SELECT SUM(CASE WHEN t.b = 1 THEN 1 ELSE 1 END) OVER (PARTITION BY t.a)
FROM t AS t1 LEFT JOIN T ON true;
ERROR: XX000: wrong varnullingrels (b) (expected (b 3)) for Var 2/1
LOCATION: search_indexed_tlist_for_var, setrefs.c:2901
Hi,
I've been investigating for a while and here are my findings.
During the parse stage, we set the
Later, when rewriting the parse tree in
Unfortunately, we overlooked updating the
As a result, when we enter
While we do have another target entry with the correct
Currently, I don't have a solid fix.
One potential solution is to correct the
However, this approach may require exposing the
It appears that the virtual column generation function during the rewrite stage does not account for the
--
Zhang Mingli
HashData
I've been investigating for a while and here are my findings.
During the parse stage, we set the
Var->varnullingrels
in the parse_analyze_fixedparams
function. Later, when rewriting the parse tree in
pg_rewrite_query()
to expand virtual columns, we replace the expression column b
with a new Var
that includes a
, since b
is defined as a * 1
. Unfortunately, we overlooked updating the
Var->varnullingrels
at this point.As a result, when we enter
search_indexed_tlist_for_var
, it leads to a failure. While we do have another target entry with the correct
varnullingrels
, the expression involving the virtual column generates another column reference, which causes the error.Currently, I don't have a solid fix.
One potential solution is to correct the
Vars
at or after the rewrite stage by traversing the parse tree again using markNullableIfNeeded
. However, this approach may require exposing the
ParseState
, which doesn't seem ideal.It appears that the virtual column generation function during the rewrite stage does not account for the
Var
field settings, leading to the errors we are encountering.--
Zhang Mingli
HashData
В списке pgsql-hackers по дате отправления: