Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_get_viewdef() and lateral references in COLUMNS of GRAPH_TABLE

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

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-18T07:56:19Z

    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.

Thanks,
Satya

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

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-04-21T06:51:56Z

    On Sat, Apr 18, 2026 at 1:26 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.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.

-- 
Best Wishes,
Ashutosh Bapat

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

    SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2026-04-21T08:02:43Z

    Hi Ashutosh,

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

> On Sat, Apr 18, 2026 at 1:26 PM SATYANARAYANA NARLAPURAM
> <satyanarlapuram@gmail.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

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

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-24T07:18:12Z

    On 21.04.26 10:02, SATYANARAYANA NARLAPURAM wrote:
>     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.

committed