Re: SQL Property Graph Queries (SQL/PGQ) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SQL Property Graph Queries (SQL/PGQ)
Date
Msg-id 0553858e-ab9b-4fda-a505-85914cee06c3@eisentraut.org
Whole thread Raw
In response to Re: SQL Property Graph Queries (SQL/PGQ)  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On 27.03.26 14:47, Ashutosh Bapat wrote:
> On Fri, Mar 27, 2026 at 3:28 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> On 26.03.26 08:08, Ashutosh Bapat wrote:
>>> Consider following query
>>> Query1
>>> SELECT x1.a, g.* FROM x1, GRAPH_TABLE (myshop MATCH (x1 IS
>>> customers)-[IS customer_orders]->(o IS orders WHERE o.order_id = x1.a)
>>> COLUMNS (x1.name AS customer_name, x1.customer_id AS cid)) g;
>>>
>>> x1 is a table referenced in from clause as well as an element pattern
>>> variable in path pattern. If we don't allow backward (cross)
>>> referencing, x1.a in the element pattern o resolves to the table x1's
>>> column a, but x1.name resolves to element x1's property reference
>>> name. So within the same graph pattern x1 may get resolved to two
>>> different things, even though x1 was declared before using it. Is that
>>> how we expect it to happen? Let's call this inconsistency1.
>>
>> I don't think this interpretation is correct.
>>
>> Even if we don't support non-local element variable references, we still
>> need to *recognize* them.  We just don't need to be able to process
>> them, we can error out if we see them.
> 
> patch 0002 in the attached patchset implements it this way. It
> collects all the element variables before transforming the path
> pattern. Later it uses this list to detect non-local variable
> references and throws error.
> 
> While implementing this I found another bug. In trasformColumnRef() we
> try to resolve the column ref as a table.column first which may
> resolve a property reference if a lateral table has the same name as
> the variable name and has a column with the same name as a property.
> Given that variables in the GRAPH_TABLE form the innermost namespace,
> we should try resolving the column reference as a property before
> lateral table reference. Since we do not allow subquery inside
> GRAPH_TABLE, there is no way a tables/columns/function will form the
> innermost namespace. The patch has a test demonstrating the bug and
> also the fix. Please let me know what you do you think of the fix.

both committed




pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Add GoAway protocol message for graceful but fast server shutdown/switchover
Next
From: Christoph Berg
Date:
Subject: Re: pgsql: test_aio: Add basic tests for StartReadBuffers()