Re: Bug: pg_get_viewdef() fails on GRAPH_TABLE views with lateral column references

From: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bug: pg_get_viewdef() fails on GRAPH_TABLE views with lateral column references
Date: 2026-04-21 08:02:43
Message-ID: CAHg+QDe2=EzNGraOnEMX6G2PYLp599JBXMMJT4gw6tJfFAsXcg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ashutosh,

On Mon, Apr 20, 2026 at 11:52 PM Ashutosh Bapat <
ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:

> On Sat, Apr 18, 2026 at 1:26 PM SATYANARAYANA NARLAPURAM
> <satyanarlapuram(at)gmail(dot)com> wrote:
> >
> > Hi hackers,
> >
> > pg_get_viewdef() fails with ERROR: bogus varlevelsup: 0 offset 0 for any
> > view containing a GRAPH_TABLE whose COLUMNS clause references an outer
> (lateral)
> > table. This also breaks pg_dump and \d+ for any database containing such
> 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 =
> NIL, so when get_rule_expr()
> > reaches a Var node, get_variable() sees list_length(context->namespaces)
> == 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-04-21 08:35:42 Re: A very quick observation of dangling pointers in Postgres pathlists
Previous Message SATYANARAYANA NARLAPURAM 2026-04-21 07:58:58 Re: [Bug][patch]: After dropping the last label from a property graph element, invoking pg_get_propgraphdef() triggers an assertion failure