Re: SQL Property Graph Queries (SQL/PGQ)

Hi Henson,

On Sat, Mar 28, 2026 at 9:03 PM Henson Choi <assam258(at)gmail(dot)com> wrote:
>
> Hi Ashutosh and Junwang,
>
>> > 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.
>
>
> I applied both patches (0001 and 0002) and ran some extended testing
> beyond the included regression tests. All non-local cross-references
> are properly rejected across every combination I tried:
>
> vertex <-> edge cross-references:
> - vertex WHERE referencing a later edge (forward) -> ERROR
> - vertex WHERE referencing an earlier edge (backward) -> ERROR
> - edge WHERE referencing a later vertex (forward) -> ERROR
> - edge WHERE referencing an earlier vertex (backward) -> ERROR
>
> longer patterns ()-[]->()-[]->():
> - 3rd vertex -> 1st vertex (long backward) -> ERROR
> - 1st edge -> 3rd vertex (long forward) -> ERROR
> - 2nd vertex -> 1st vertex (adjacent backward) -> ERROR
> - 2nd vertex -> 3rd vertex (adjacent forward) -> ERROR
> - 1st vertex -> 3rd vertex (long forward) -> ERROR
> - all references local -> OK
>
> All combinations -- vertex-vertex, vertex-edge, edge-vertex, adjacent
> and long-distance -- are blocked as expected. Looks good.
>
>> Seeing the comment above transformGraphTablePropertyRef:
>>
>> *
>> * A property reference is parsed as a ColumnRef of the form:
>> * <variable>.<property>. If <variable> is one of the variables bound to an
>> * element pattern in the graph pattern and <property> can be resolved as a
>> * property of the property graph, then we return a GraphPropertyRef node
>>
>> it seems to imply that G041 is supported. Should we update this comment
>> to better reflect the current behavior?
>
>
> Agreed, it would be nice to update the comment to reflect that
> non-local element variable references are now rejected.
>
>>
>> I have a question about this. Why do we allow a ColumnRef to reference a
>> lateral table outside the graph pattern?
>>
>> For example, in the following query:
>>
>> SELECT x1.a, g.*
>> FROM x1,
>> GRAPH_TABLE (
>> myshop
>> MATCH (x1 IS customers WHERE address = 'US')
>> -[IS customer_orders]->(o IS orders)
>> COLUMNS (x1.name AS customer_name,
>> x1.customer_id AS cid,
>> o.order_id)
>> ) g;
>>
>> It’s easy for users to get confused and assume that `address` is a column
>> of customers rather than the outside x1.
>
>
>
>
> GRAPH_TABLE has implicit LATERAL semantics per the SQL standard
> (ISO/IEC 9075-16, Syntax Rule 5 of Subclause 7.6: <graph table derived
> table> is added to the list of <table primary>s that support lateral
> join), so referencing outer FROM items is expected behavior.

Okay, thanks for sharing this. My copy of SQL/PGQ seems
incomplete, it only includes subclauses 7.1 and 7.2 ;(

>
> When the FROM table name doesn't conflict with an element variable,
> lateral references work as expected:
>
> SELECT x2.a, g.*
> FROM x2,
> GRAPH_TABLE (myshop
> MATCH (c IS customers WHERE c.address = 'US'
> AND c.customer_id = x2.a)
> -[IS customer_orders]->(o IS orders)
> COLUMNS (c.name AS customer_name,
> c.customer_id AS cid, o.order_id)) g;
> -- OK: x2.a resolves to lateral table x2
>
> But when the same name is used for both (as in your example with x1),
> qualified references are always captured by the element variable:
>
> SELECT x1.a, g.*
> FROM x1,
> GRAPH_TABLE (myshop
> MATCH (x1 IS customers WHERE x1.address = 'US')
> -[IS customer_orders]->(o IS orders
> WHERE o.order_id = x1.a)
> COLUMNS (x1.name AS customer_name,
> x1.customer_id AS cid, o.order_id)) g;
> -- ERROR: non-local element variable reference is not supported
> -- x1.a is recognized as element variable x1, not lateral table x1
>
> I agree this can be a bit confusing for users, but given that PGQ is
> still in its early stage, prioritizing stability seems reasonable
> for now. This should be resolved once G041 support is added in the
> future.

Agreed, thanks.

>
> Best Regards,
> Henson

--
Regards
Junwang Zhao