Re: GRAPH_TABLE: lateral reference with label disjunction fails with "plan should not reference subplan's variable"

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, peter(at)eisentraut(dot)org
Subject: Re: GRAPH_TABLE: lateral reference with label disjunction fails with "plan should not reference subplan's variable"
Date: 2026-06-04 09:55:05
Message-ID: CAExHW5vKmi_jMvd-OmG8OHytifQp0oKWP4p55FPCfL9V5Qn1Sg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ewan,
Thanks for trying out SQL/PGQ and the report.

On Thu, Jun 4, 2026 at 1:58 PM Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
>
> Hi hackers,
>
> While testing with master I ran into an internal error in the
> SQL/PGQ code (commit 2f094e7ac69). A lateral reference into a
> GRAPH_TABLE clause whose graph pattern contains a label disjunction
> resolving to more than one element table fails at plan time:
>
> CREATE TABLE v1 (id int);
> CREATE TABLE v2 (id int);
> CREATE TABLE x (a int);
> CREATE PROPERTY GRAPH g
> VERTEX TABLES (v1 KEY (id) LABEL l1, v2 KEY (id) LABEL l2);
>
> SELECT 1 FROM x,
> GRAPH_TABLE (g MATCH (s IS l1|l2 WHERE s.id = x.a) COLUMNS (s.id));
> ERROR: plan should not reference subplan's variable
>
> The same pattern with a single label works fine, as does a label
> disjunction without the lateral reference. Reproduces on any build of
> master and 19beta1; the equivalent hand-written query (LATERAL over a
> UNION ALL) plans fine.
>
> The cause is in rewriteGraphTable.c. replace_property_refs_mutator()
> increments varlevelsup of lateral references by one, assuming the path
> query will directly become the GRAPH_TABLE's subquery. That holds for
> a single path query, but when the disjunction produces several path
> queries, generate_union_from_pathqueries() wraps them in subquery RTEs
> of a new UNION query, one level deeper, and nothing compensates for
> that. The planner then attributes the parameters to the wrong query
> level, which finalize_plan() detects.
>
> The attached patch increments the level of outer references in each
> path query once more at the point where they are wrapped in the UNION
> query, using IncrementVarSublevelsUp(). With the fix, the query above
> returns the same results as the hand-written UNION ALL equivalent.
>
> make check passes with the patch applied.

This bug is the same as the one being discussed in [1]. Let's continue
the discussion there.

[1] http://postgr.es/m/tencent_43D9888041FA4FDE498C7BF1@qq.com

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-06-04 09:58:48 Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Previous Message cca5507 2026-06-04 09:32:17 Re: Fix tuple deformation with virtual generated NOT NULL columns