SQL/PGQ: All properties reference
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t53528psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 03:08 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t53528_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t53528_1 && git checkout t53528_1Patchset v1 (message #1) is on t53528_1
Hi Peter and Pgsql-Hackers,
I am starting a new thread to discuss all properties reference feature
which was not committed with the main patch. [1]postgr.es/m/bcf58f6e-d0bd-49f8-b074-e3ee69ef6567@eisentraut.org
A <variable>.* is called all properties reference and it is allowed
only in COLUMNs clause. Interpreting subclause 9.2 and 9.3 together,
it expands to a list of graph property references <variable>.p1, ...
<variable>.pn where p1, ..., pn are the properties of the labels which
satisfy the label expression in the element pattern identified by
<variable>. The graph property references are added to the COLUMNs
clause in place of the all property reference, just like how <table>.*
expands in SELECT's targetlist.
In the current implementation, we delay resolving graph property
references (<variable>.<property>) till the time query is generated
(generate_query_for_graph_path()). If we delay the all properties
reference till that time, we can not determine the data types and
names of the columns in the COLUMNs list. So we need to do that when
the COLUMNs clause is resolved. This means that the properties
associated with the labels needs to be resolved earlier. Since the
properties are not associated with labels directly but through the
elements, we need to find at least one element for every label in the
label expression. In brief, all the namespace resolution need to
happen before we transform COLUMNs clause. The patch rearranges the
code that way.
I like the resultant code since a. it handles errors more gracefully
and can provide error location as well b. It avoids repeated property
and element label lookups c. the code seems closer to how we create
namespaces for table references. Flip side I think it fetches the
properties which may or may not be needed by the query, similar to how
we compute the tuple descriptor of a table referenced in the query
even though we don't need all the columns. But overall I think it's
better code as well.
There are some things that still need work as below
o. Order of properties in all properties reference
----------------------------------------------------------------
The standard (subclause 9.3) mentions this as implementation
dependent. Since properties are associated with labels which are a
logical entity, I don't think we need to define property numbers like
attribute numbers. Natural order is ordering by the property names
(even across the labels). Do we have any other option?
o. Difference from Oracle
----------------------------------
Consider following query from the patch (please refer the
graph_table.sql for details)
SELECT * FROM GRAPH_TABLE (g1 MATCH (src IS vl1 | vl2 WHERE src.vprop1
= 10 OR src.vprop1 = 1020) COLUMNS (src.*));
The element pattern has only two labels vl1 and vl2 in it. If I
understand subclause 9.2 and 9.3 correctly, only the properties of the
labels that appear in the label expression should be part of all
properties reference. The expected output in the patch is based on
this interpretation - which has columns vname | vprop1 | vprop2 |
lprop1 . However, Oracle includes elname as well which is not
associated with vl1 or vl2. I think, Oracle's output is wrong. But
maybe I am misinterpreting those clauses. Peter, what do you think?
o. pg_node_attrs for new fields
-----------------------------------------
Need to think about pg_node_attrs for the new members of GraphLabelRef
added in patch. Possibly the current annotation is right, but need to
check again.
o. Need to document what a <variable>.* will result into
Planning to work on it after the main patch is somewhat stable.
[1]: postgr.es/m/bcf58f6e-d0bd-49f8-b074-e3ee69ef6567@eisentraut.org
--
Best Wishes,
Ashutosh Bapat
Hi Ashutosh,
I am starting a new thread to discuss all properties reference feature
which was not committed with the main patch. [1]
A <variable>.* is called all properties reference and it is allowed
only in COLUMNs clause. Interpreting subclause 9.2 and 9.3 together,
it expands to a list of graph property references <variable>.p1, ...
<variable>.pn where p1, ..., pn are the properties of the labels which
satisfy the label expression in the element pattern identified by
<variable>. The graph property references are added to the COLUMNs
clause in place of the all property reference, just like how <table>.*
expands in SELECT's targetlist.In the current implementation, we delay resolving graph property
references (<variable>.<property>) till the time query is generated
(generate_query_for_graph_path()). If we delay the all properties
reference till that time, we can not determine the data types and
names of the columns in the COLUMNs list. So we need to do that when
the COLUMNs clause is resolved. This means that the properties
associated with the labels needs to be resolved earlier. Since the
properties are not associated with labels directly but through the
elements, we need to find at least one element for every label in the
label expression. In brief, all the namespace resolution need to
happen before we transform COLUMNs clause. The patch rearranges the
code that way.
I tried applying v20260318 on top of master to review it, but ran
into merge conflicts in two files:
- parse_graphtable.c
- rewriteGraphTable.c
The conflicts come from this commit that was added after the main PGQ
commit (2f094e7ac69):
- a0dd0702e46 Fix cross variable references in graph pattern causing
segfault
Would it be possible to rebase the patch on the current master so
I can review it cleanly?
Best Regards,
Henson
On Fri, Apr 3, 2026 at 7:24 AM Henson Choi <assam258@gmail.com> wrote:
Hi Ashutosh,
I am starting a new thread to discuss all properties reference feature
which was not committed with the main patch. [1]A <variable>.* is called all properties reference and it is allowed
only in COLUMNs clause. Interpreting subclause 9.2 and 9.3 together,
it expands to a list of graph property references <variable>.p1, ...
<variable>.pn where p1, ..., pn are the properties of the labels which
satisfy the label expression in the element pattern identified by
<variable>. The graph property references are added to the COLUMNs
clause in place of the all property reference, just like how <table>.*
expands in SELECT's targetlist.In the current implementation, we delay resolving graph property
references (<variable>.<property>) till the time query is generated
(generate_query_for_graph_path()). If we delay the all properties
reference till that time, we can not determine the data types and
names of the columns in the COLUMNs list. So we need to do that when
the COLUMNs clause is resolved. This means that the properties
associated with the labels needs to be resolved earlier. Since the
properties are not associated with labels directly but through the
elements, we need to find at least one element for every label in the
label expression. In brief, all the namespace resolution need to
happen before we transform COLUMNs clause. The patch rearranges the
code that way.I tried applying v20260318 on top of master to review it, but ran
into merge conflicts in two files:- parse_graphtable.c
- rewriteGraphTable.cThe conflicts come from this commit that was added after the main PGQ
commit (2f094e7ac69):- a0dd0702e46 Fix cross variable references in graph pattern causing
segfaultWould it be possible to rebase the patch on the current master so
I can review it cleanly?
I want to focus on resizable shared memory structures for PG 19 [1]/messages/by-id/CAExHW5vM1bneLYfg0wGeAa=52UiJ3z4vKd3AJ72X8Fw6k3KKrg@mail.gmail.com in
whatever time remains until the feature freeze. If Peter feels that we
should get this in PG 19, I will rebase and finish the patch. I am ok,
if somebody else wants to rebase and finish this for PG 19 as well.
Sorry if this patch slips PG 19, but I will pick it up for PG 20, once
the branch opens.
[1]: /messages/by-id/CAExHW5vM1bneLYfg0wGeAa=52UiJ3z4vKd3AJ72X8Fw6k3KKrg@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat