Re: GRAPH_TABLE pattern WHERE clause is not coerced to boolean

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: GRAPH_TABLE pattern WHERE clause is not coerced to boolean
Date: 2026-09-02 19:15:49
Message-ID: 28560946-2409-43f4-8400-7355c05c5cb5@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31.08.26 09:32, Ewan Young wrote:
> Hi
>
> The WHERE clauses inside a GRAPH_TABLE pattern -- both the element-level
> one (MATCH (c IS customers WHERE ...)) and the graph-pattern-level one
> (MATCH ... WHERE ...) -- are transformed with a bare transformExpr()
> and never go through coerce_to_boolean(). So a WHERE clause of any
> type is accepted, and its raw datum is used as the qual:
>
> create table customers (id int primary key, name text);
> insert into customers values (1,'alice'),(2,null),(3,'carol');
> create property graph g
> vertex tables (customers key (id) label customer properties (id, name));
>
> select * from graph_table (g match (c is customer where c.name)
> columns (c.id));
> id
> ----
> 1
> 3
> (2 rows)
>
> EXPLAIN shows "Filter: name". The never-null text pointer is always
> taken as true, so the condition silently degenerates to roughly
> "name IS NOT NULL": the NULL-name row disappears with no error.
> Numeric quals are evaluated by bit pattern ("WHERE 1" is true,
> "WHERE 0" is false), and even "WHERE row(1,2)" is accepted. The same
> clause outside GRAPH_TABLE gives the usual
>
> ERROR: argument of WHERE must be type boolean, not type text
>
> The attached patch routes both sites through transformWhereClause(),
> like every other WHERE clause, and adds regression tests for the
> element-level and pattern-level cases. make check passes. The code is
> the same in REL_19_STABLE, so v19 is affected as well.

Fixed, thanks.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2026-09-02 19:29:06 Re: PGQ catalog representation and pg_dump support
Previous Message Jelte Fennema-Nio 2026-09-02 19:14:04 Re: Bypassing cursors in postgres_fdw to enable parallel plans