postgres.email
❮

[PATCH] Improve error message for graph variable references in subqueries within GRAPH_TABLE

  • Jump to comment-1
    SATYANARAYANA NARLAPURAM<satyanarlapuram@gmail.com>
    Apr 25, 2026, 5:11 PM UTC
    Hi Hackers,
    When a subquery inside GRAPH_TABLE COLUMNS or MATCH WHERE references a
    graph pattern variable, the error was a confusing "missing FROM-clause
    entry for table". Fix by walking the parentParseState chain in
    transformGraphTablePropertyRef() to detect the graph variable and report
    a clear "cannot be used in a subquery" error instead.
    Based on the below comment and code in transformRangeGraphTable I am
    assuming we don't support
    subqueries for now.
    /*
    * If we support subqueries within GRAPH_TABLE, those need to be
    * propagated to the queries resulting from rewriting graph table RTE. We
    * don't do that right now, hence prohibit it for now.
    */
    if (pstate->p_hasSubLinks)
    ereport(ERROR,
    (errcode(ERRCODEFEATURENOT_SUPPORTED),
    errmsg("subqueries within GRAPH_TABLE reference are not supported")));
    pstate->phasSubLinks = savedhasSublinks;
    Attached a patch to address this which also includes a test.
    Thanks,
    Satya
    View in PostgreSQL Archives →
    • Jump to comment-1
      Ashutosh Bapat<ashutosh.bapat.oss@gmail.com>
      Apr 29, 2026, 2:00 PM UTC
      On Sat, Apr 25, 2026 at 10:42 PM SATYANARAYANA NARLAPURAM
      <satyanarlapuram@gmail.com> wrote:

      Hi Hackers,

      When a subquery inside GRAPH_TABLE COLUMNS or MATCH WHERE references a
      graph pattern variable, the error was a confusing "missing FROM-clause
      entry for table". Fix by walking the parentParseState chain in
      transformGraphTablePropertyRef() to detect the graph variable and report
      a clear "cannot be used in a subquery" error instead.


      Based on the below comment and code in transformRangeGraphTable I am assuming we don't support
      subqueries for now.

      /*
      * If we support subqueries within GRAPH_TABLE, those need to be
      * propagated to the queries resulting from rewriting graph table RTE. We
      * don't do that right now, hence prohibit it for now.
      */
      if (pstate->p_hasSubLinks)
      ereport(ERROR,
      (errcode(ERRCODEFEATURENOT_SUPPORTED),
      errmsg("subqueries within GRAPH_TABLE reference are not supported")));
      pstate->phasSubLinks = savedhasSublinks;
      We don't support subqueries in GRAPH_TABLE for now.
      However, I don't think this is the right fix. Consider a query like
      SELECT * FROM GRAPH_TABLE (g1 MATCH (src IS vl1)
COLUMNS (src.vname AS sname,
(SELECT * FROM t1 src WHERE a > (SELECT count(*) FROM v1 WHERE vprop1
= src.vprop1) AS cnt))) gt;
      The src referenced in the innermost subquery should be resolved to the
      t1 in its outer query. That will happen when the column reference
      walks the parser state stack. However, since we call
      transformGraphPropertyRef() before trying to resolve a column ref as a
      column ref, your changes will throw a premature error "graph pattern
      variable reference \"%s\" cannot be used in a subquery". I don't think
      that's right. A better fix might be to detect a subquery within
      GRAPH_TABLE before transforming the subquery and throw "subqueries
      within GRAPH_TABLE reference are not supported" error there. That may
      be tricky to do, since parse states created between the parse state
      which has graph state and parse state of the subquery all have to
      carry a flag indicating the existence of a graph table somewhere up
      the stack.
      --
      Best Wishes,
      Ashutosh Bapat
      View in PostgreSQL Archives →