MIME-Version: 1.0
References: 
 <CAHg+QDcLVa2iBnggkHxY4itZbXtDMfsYHEjnCUYe9hNbnxDi-w@mail.gmail.com>
 <CAExHW5tOhqm7U0Yvsj=aEQWefKnD-ijpT2YzCCrDNJYm=QQu2Q@mail.gmail.com>
In-Reply-To: 
 <CAExHW5tOhqm7U0Yvsj=aEQWefKnD-ijpT2YzCCrDNJYm=QQu2Q@mail.gmail.com>
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Tue, 21 Apr 2026 01:02:43 -0700
Message-ID: 
 <CAHg+QDe2=EzNGraOnEMX6G2PYLp599JBXMMJT4gw6tJfFAsXcg@mail.gmail.com>
Subject: Re: Bug: pg_get_viewdef() fails on GRAPH_TABLE views with lateral
 column references
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000cd987c064ff3d76a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDe2%3DEzNGraOnEMX6G2PYLp599JBXMMJT4gw6tJfFAsXcg%40mail.gmail.com>
Precedence: bulk

--000000000000cd987c064ff3d76a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ashutosh,

On Mon, Apr 20, 2026 at 11:52=E2=80=AFPM Ashutosh Bapat <
ashutosh.bapat.oss@gmail.com> wrote:

> On Sat, Apr 18, 2026 at 1:26=E2=80=AFPM SATYANARAYANA NARLAPURAM
> <satyanarlapuram@gmail.com> wrote:
> >
> > Hi hackers,
> >
> > pg_get_viewdef() fails with ERROR: bogus varlevelsup: 0 offset 0 for an=
y
> > view containing a GRAPH_TABLE whose COLUMNS clause references an outer
> (lateral)
> > table. This also breaks pg_dump and \d+ for any database containing suc=
h
> a
> > view.
> >
> > Repro:
> >
> > CREATE TABLE vtab (id int PRIMARY KEY, name text);
> > CREATE TABLE etab (eid int PRIMARY KEY,
> >     src int REFERENCES vtab(id), dst int REFERENCES vtab(id));
> > CREATE PROPERTY GRAPH g1
> >     VERTEX TABLES (vtab)
> >     EDGE TABLES (etab KEY (eid)
> >         SOURCE KEY (src) REFERENCES vtab(id)
> >         DESTINATION KEY (dst) REFERENCES vtab(id));
> > CREATE TABLE outer_t (val int);
> >
> > CREATE VIEW v AS
> >   SELECT * FROM outer_t,
> >     GRAPH_TABLE (g1 MATCH (a IS vtab)
> >       COLUMNS (a.name AS src_name, outer_t.val AS oval));
> >
> > pg_dump -d foo -p 5433
> > pg_dump: error: query failed: ERROR:  bogus varlevelsup: 0 offset 0
> > pg_dump: detail: Query was: SELECT
> pg_catalog.pg_get_viewdef('173849'::pg_catalog.oid) AS viewdef
> >
> > Problem:
> > deparse_context context variable declared in the case RTE_GRAPH_TABLE
> shadows the function's
> > deparse_context *context parameter. The zeroed struct has namespaces =
=3D
> NIL, so when get_rule_expr()
> > reaches a Var node, get_variable() sees list_length(context->namespaces=
)
> =3D=3D 0 and raises the error. Property
> > references are fine because GraphPropertyRef deparsing never touches
> namespaces.
> >
> > Fix:
> > Remove the shadowing local variable and pass the outer context pointer
> to get_rule_expr(). Attached a patch
> > with a fix, additionally added a test.
>
> The code doesn't explain why it adds the dummy context but it seemed
> intentional. But it's not used at other places like deparsing WHERE
> clause in element patterns or that in the graph_table itself. Since a
> lateral reference is allowed in COLUMNS clause as well, it doesn't
> make sense not to pass a context with lateral namespaces. Also there
> is no comment explaining the dummy context. So your fix looks good to
> me. I adjusted the surrounding code a bit.
>
> I adjusted an existing view for the testing instead of adding a new
> one with all the additional objects. Since that view definition was
> getting more complex, I formatted the DDL to be more readable.
>
> I also think that we should use prettyFlags to deparse all GRAPH_TABLE
> components in a human readable form. But that's out of the scope for
> this patch.
>
> PFA updated patch.
>

Thank you for updating the patch. It applies cleanly and the related tests
are passing.


Thanks,
Satya

--000000000000cd987c064ff3d76a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ashutosh,</div><br><div class=3D"gmail=
_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,=
 Apr 20, 2026 at 11:52=E2=80=AFPM Ashutosh Bapat &lt;<a href=3D"mailto:ashu=
tosh.bapat.oss@gmail.com">ashutosh.bapat.oss@gmail.com</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Apr 18, 2026 =
at 1:26=E2=80=AFPM SATYANARAYANA NARLAPURAM<br>
&lt;<a href=3D"mailto:satyanarlapuram@gmail.com" target=3D"_blank">satyanar=
lapuram@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi hackers,<br>
&gt;<br>
&gt; pg_get_viewdef() fails with ERROR: bogus varlevelsup: 0 offset 0 for a=
ny<br>
&gt; view containing a GRAPH_TABLE whose COLUMNS clause references an outer=
 (lateral)<br>
&gt; table. This also breaks pg_dump and \d+ for any database containing su=
ch a<br>
&gt; view.<br>
&gt;<br>
&gt; Repro:<br>
&gt;<br>
&gt; CREATE TABLE vtab (id int PRIMARY KEY, name text);<br>
&gt; CREATE TABLE etab (eid int PRIMARY KEY,<br>
&gt;=C2=A0 =C2=A0 =C2=A0src int REFERENCES vtab(id), dst int REFERENCES vta=
b(id));<br>
&gt; CREATE PROPERTY GRAPH g1<br>
&gt;=C2=A0 =C2=A0 =C2=A0VERTEX TABLES (vtab)<br>
&gt;=C2=A0 =C2=A0 =C2=A0EDGE TABLES (etab KEY (eid)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SOURCE KEY (src) REFERENCES vtab(id)<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DESTINATION KEY (dst) REFERENCES vtab=
(id));<br>
&gt; CREATE TABLE outer_t (val int);<br>
&gt;<br>
&gt; CREATE VIEW v AS<br>
&gt;=C2=A0 =C2=A0SELECT * FROM outer_t,<br>
&gt;=C2=A0 =C2=A0 =C2=A0GRAPH_TABLE (g1 MATCH (a IS vtab)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0COLUMNS (<a href=3D"http://a.name" rel=3D"no=
referrer" target=3D"_blank">a.name</a> AS src_name, outer_t.val AS oval));<=
br>
&gt;<br>
&gt; pg_dump -d foo -p 5433<br>
&gt; pg_dump: error: query failed: ERROR:=C2=A0 bogus varlevelsup: 0 offset=
 0<br>
&gt; pg_dump: detail: Query was: SELECT pg_catalog.pg_get_viewdef(&#39;1738=
49&#39;::pg_catalog.oid) AS viewdef<br>
&gt;<br>
&gt; Problem:<br>
&gt; deparse_context context variable declared in the case RTE_GRAPH_TABLE =
shadows the function&#39;s<br>
&gt; deparse_context *context parameter. The zeroed struct has namespaces =
=3D NIL, so when get_rule_expr()<br>
&gt; reaches a Var node, get_variable() sees list_length(context-&gt;namesp=
aces) =3D=3D 0 and raises the error. Property<br>
&gt; references are fine because GraphPropertyRef deparsing never touches n=
amespaces.<br>
&gt;<br>
&gt; Fix:<br>
&gt; Remove the shadowing local variable and pass the outer context pointer=
 to get_rule_expr(). Attached a patch<br>
&gt; with a fix, additionally added a test.<br>
<br>
The code doesn&#39;t explain why it adds the dummy context but it seemed<br=
>
intentional. But it&#39;s not used at other places like deparsing WHERE<br>
clause in element patterns or that in the graph_table itself. Since a<br>
lateral reference is allowed in COLUMNS clause as well, it doesn&#39;t<br>
make sense not to pass a context with lateral namespaces. Also there<br>
is no comment explaining the dummy context. So your fix looks good to<br>
me. I adjusted the surrounding code a bit.<br>
<br>
I adjusted an existing view for the testing instead of adding a new<br>
one with all the additional objects. Since that view definition was<br>
getting more complex, I formatted the DDL to be more readable.<br>
<br>
I also think that we should use prettyFlags to deparse all GRAPH_TABLE<br>
components in a human readable form. But that&#39;s out of the scope for<br=
>
this patch.<br>
<br>
PFA updated patch.<br></blockquote><div><br></div><div>Thank you for updati=
ng the patch. It applies cleanly and the related tests are passing.=C2=A0</=
div><div><br></div><div><br></div><div>Thanks,</div><div>Satya=C2=A0</div><=
/div></div>

--000000000000cd987c064ff3d76a--