On 17.12.25 06:32, Ashutosh Bapat wrote:
On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
<[email protected]> wrote:
Rebased patches on the latest HEAD which required me to move
graph_table.sql to another parallel group.
Huh, the movement resulted in losing that test from parallel_schedule.
Fixed in the attached patches.
A couple of items:
1) I was running some tests that involved properties with mismatching
typmods, and I got an error message like
ERROR: property "p1" data type modifier mismatch: 14 vs. 19
but the actual types were varchar(10) and varchar(15). So to improve
that, we need to run these through the typmod formatting routines, not
just print the raw typmod numbers. I actually just combined that with
the check for the type itself. Also, there was no test covering this,
so I added one. See attached patches.
I did another investigation about whether this level of checking is
necessary. I think according to the letter of the SQL standard, the
typmods must indeed match. It seems Oracle does not check (the example
mentioned above came from an Oracle source). But I think it's okay to
keep the check. In PostgreSQL, it is much less common to write like
varchar(1000). And we can always consider relaxing it later.
2) I had it in my notes to consider whether we should support the colon
syntax for label expressions. I think we might have talked about that
before.
I'm now leaning toward not supporting it in the first iteration. I
don't know that we have fully explored possible conflicts with host
variable syntax in ecpg and psql and the like. Maybe avoid that for now.
There was also a bit of an inconsistency in the presentation: The
documentation introduced the colon as seemingly the preferred syntax,
but ruleutils.c dumped out the IS syntax.
(It was also a bit curious that some test code put spaces around the
colon, which is not idiomatic.)
Looking around at other implementations: Oracle does not support it;
DuckDB supports it, but it doesn't seem to be very up to date, so I
don't know what the thinking there is; Google does support it, but it
seems their syntax is more of a PGQ-GQL hybrid, so it's not a good
reference.
Attached is a patch that shows how to revert the colon support. It's
pretty simple, and it would be easy to add it back in later, I think.
From dda1111723540174c40e25e59cce587b20897eea Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Wed, 17 Dec 2025 08:37:15 +0100
Subject: [PATCH 1/3] Add test for properties typmod mismatch
---
src/test/regress/expected/create_property_graph.out | 10 ++++++++++
src/test/regress/sql/create_property_graph.sql | 9 +++++++++
2 files changed, 19 insertions(+)
diff --git a/src/test/regress/expected/create_property_graph.out
b/src/test/regress/expected/create_property_graph.out
index dbaf65c4d59..d177159ed72 100644
--- a/src/test/regress/expected/create_property_graph.out
+++ b/src/test/regress/expected/create_property_graph.out
@@ -162,6 +162,16 @@ DETAIL: In a property graph, a property of the same name
has to have the same d
ALTER PROPERTY GRAPH g2 ALTER VERTEX TABLE t1 ADD LABEL foo PROPERTIES (b AS
k); -- type mismatch
ERROR: property "k" data type mismatch: integer vs. text
DETAIL: In a property graph, a property of the same name has to have the same
data type in each label.
+CREATE TABLE t1x (a int, b varchar(10));
+CREATE TABLE t2x (i int, j varchar(15));
+CREATE PROPERTY GRAPH gx
+ VERTEX TABLES (
+ t1x KEY (a) PROPERTIES (b AS p1),
+ t2x KEY (i) PROPERTIES (j AS p1) -- typmod mismatch
+ );
+ERROR: property "p1" data type modifier mismatch: 14 vs. 19
+DETAIL: In a property graph, a property of the same name has to have the same
type modifier in each label.
+DROP TABLE t1x, t2x;
CREATE PROPERTY GRAPH gx
VERTEX TABLES (
t1 KEY (a) LABEL l1 PROPERTIES (a, a AS aa),
diff --git a/src/test/regress/sql/create_property_graph.sql
b/src/test/regress/sql/create_property_graph.sql
index 6ace22fe7c9..ab73e340cc3 100644
--- a/src/test/regress/sql/create_property_graph.sql
+++ b/src/test/regress/sql/create_property_graph.sql
@@ -126,6 +126,15 @@ CREATE PROPERTY GRAPH gx
);
ALTER PROPERTY GRAPH g2 ALTER VERTEX TABLE t1 ADD LABEL foo PROPERTIES (b AS
k); -- type mismatch
+CREATE TABLE t1x (a int, b varchar(10));
+CREATE TABLE t2x (i int, j varchar(15));
+CREATE PROPERTY GRAPH gx
+ VERTEX TABLES (
+ t1x KEY (a) PROPERTIES (b AS p1),
+ t2x KEY (i) PROPERTIES (j AS p1) -- typmod mismatch
+ );
+DROP TABLE t1x, t2x;
+
CREATE PROPERTY GRAPH gx
VERTEX TABLES (
t1 KEY (a) LABEL l1 PROPERTIES (a, a AS aa),
--
2.52.0
From 29afc47421916649825ca173a060da791e4ca21f Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Wed, 17 Dec 2025 08:39:47 +0100
Subject: [PATCH 2/3] Improve error message for property typmod mismatch
We should print the formatted type, not the raw typmod.
---
src/backend/commands/propgraphcmds.c | 21 ++-----------------
.../expected/create_property_graph.out | 4 ++--
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/src/backend/commands/propgraphcmds.c
b/src/backend/commands/propgraphcmds.c
index c1a9e553f16..9d8291e1b4e 100644
--- a/src/backend/commands/propgraphcmds.c
+++ b/src/backend/commands/propgraphcmds.c
@@ -974,12 +974,12 @@ insert_property_record(Oid graphid, Oid ellabeloid, Oid
pgerelid, const char *pr
* subclause "Consistency check of a tabular property graph
* descriptor".)
*/
- if (proptypid != exprtypid)
+ if (proptypid != exprtypid || proptypmod != exprtypmod)
{
ereport(ERROR,
errcode(ERRCODE_SYNTAX_ERROR),
errmsg("property \"%s\" data type
mismatch: %s vs. %s",
- propname,
format_type_be(proptypid), format_type_be(exprtypid)),
+ propname,
format_type_with_typemod(proptypid, proptypmod),
format_type_with_typemod(exprtypid, exprtypmod)),
errdetail("In a property graph, a
property of the same name has to have the same data type in each label."));
}
@@ -992,23 +992,6 @@ insert_property_record(Oid graphid, Oid ellabeloid, Oid
pgerelid, const char *pr
propname,
get_collation_name(propcollation), get_collation_name(exprcollation)),
errdetail("In a property graph, a
property of the same name has to have the same collation in each label."));
}
-
- /*
- * And typmod. It does not seem to be necessary to enforce
typmod
- * consistency across properties with the same name. But when
- * properties with the same name have different typmods, it is
not
- * clear which one should be used as the typmod of the graph
property
- * when typmod of a property is requested before fetching any
of the
- * property expressions.
- */
- if (proptypmod != exprtypmod)
- {
- ereport(ERROR,
- errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("property \"%s\" data type
modifier mismatch: %d vs. %d",
- propname, proptypmod,
exprtypmod),
- errdetail("In a property graph, a
property of the same name has to have the same type modifier in each label."));
- }
}
/*
diff --git a/src/test/regress/expected/create_property_graph.out
b/src/test/regress/expected/create_property_graph.out
index d177159ed72..0e21600e8d7 100644
--- a/src/test/regress/expected/create_property_graph.out
+++ b/src/test/regress/expected/create_property_graph.out
@@ -169,8 +169,8 @@ CREATE PROPERTY GRAPH gx
t1x KEY (a) PROPERTIES (b AS p1),
t2x KEY (i) PROPERTIES (j AS p1) -- typmod mismatch
);
-ERROR: property "p1" data type modifier mismatch: 14 vs. 19
-DETAIL: In a property graph, a property of the same name has to have the same
type modifier in each label.
+ERROR: property "p1" data type mismatch: character varying(10) vs. character
varying(15)
+DETAIL: In a property graph, a property of the same name has to have the same
data type in each label.
DROP TABLE t1x, t2x;
CREATE PROPERTY GRAPH gx
VERTEX TABLES (
--
2.52.0
From e8830a0cc1bf15c819ca7235767513b759eeb5e5 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
Date: Wed, 17 Dec 2025 09:37:46 +0100
Subject: [PATCH 3/3] Remove support for colon in 'is label' expression
---
.../expected/pg_overexplain.out | 2 +-
contrib/pg_overexplain/sql/pg_overexplain.sql | 2 +-
doc/src/sgml/queries.sgml | 32 ++++++++-----------
src/backend/catalog/sql_features.txt | 2 +-
src/backend/parser/gram.y | 1 -
src/test/regress/expected/graph_table.out | 10 +++---
src/test/regress/expected/graph_table_rls.out | 4 +--
src/test/regress/expected/privileges.out | 22 ++++++-------
src/test/regress/sql/graph_table.sql | 10 +++---
src/test/regress/sql/graph_table_rls.sql | 4 +--
src/test/regress/sql/privileges.sql | 22 ++++++-------
11 files changed, 52 insertions(+), 59 deletions(-)
diff --git a/contrib/pg_overexplain/expected/pg_overexplain.out
b/contrib/pg_overexplain/expected/pg_overexplain.out
index 2b120315a7f..643629296e6 100644
--- a/contrib/pg_overexplain/expected/pg_overexplain.out
+++ b/contrib/pg_overexplain/expected/pg_overexplain.out
@@ -497,7 +497,7 @@ VERTEX TABLES
brassica KEY(name) DEFAULT LABEL LABEL vegetables
);
EXPLAIN (RANGE_TABLE, COSTS OFF)
-SELECT * FROM GRAPH_TABLE (vegetables_graph MATCH (v1:vegetables) WHERE
v1.genus = 'daucus' COLUMNS (v1.name));
+SELECT * FROM GRAPH_TABLE (vegetables_graph MATCH (v1 IS vegetables) WHERE
v1.genus = 'daucus' COLUMNS (v1.name));
QUERY PLAN
----------------------------------------------
Append
diff --git a/contrib/pg_overexplain/sql/pg_overexplain.sql
b/contrib/pg_overexplain/sql/pg_overexplain.sql
index 2d1d0f4ac95..0eb18be76b6 100644
--- a/contrib/pg_overexplain/sql/pg_overexplain.sql
+++ b/contrib/pg_overexplain/sql/pg_overexplain.sql
@@ -120,4 +120,4 @@ CREATE PROPERTY GRAPH vegetables_graph
);
EXPLAIN (RANGE_TABLE, COSTS OFF)
-SELECT * FROM GRAPH_TABLE (vegetables_graph MATCH (v1:vegetables) WHERE
v1.genus = 'daucus' COLUMNS (v1.name));
+SELECT * FROM GRAPH_TABLE (vegetables_graph MATCH (v1 IS vegetables) WHERE
v1.genus = 'daucus' COLUMNS (v1.name));
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
index fccf049cb35..ec4ca01cd16 100644
--- a/doc/src/sgml/queries.sgml
+++ b/doc/src/sgml/queries.sgml
@@ -2861,28 +2861,22 @@ <title>Graph Patterns</title>
for elements (vertices and edges) that have certain characteristics.
These characteristics are written in between the parentheses or brackets.
(This is also called an element pattern filler.) Typically, we would
- search for elements with a certain label. This is written either by
- <literal>IS <replaceable>labelname</replaceable></literal> or equivalently
- <literal>:<replaceable>labelname</replaceable></literal>. For example,
- this would match all vertices with the label <literal>person</literal>:
+ search for elements with a certain label. This is written by <literal>IS
+ <replaceable>labelname</replaceable></literal>. For example, this would
+ match all vertices with the label <literal>person</literal>:
<programlisting>
(IS person)
</programlisting>
- or
-<programlisting>
-(:person)
-</programlisting>
- (From now on, we will just use the colon syntax, for simplicity. But it
- helps to read it as <quote>is</quote> for understanding.) The next
+ The next
example would match a vertex with the label <literal>person</literal>
connected to a vertex with the label <literal>account</literal> connected
by an edge with the label <literal>has</literal>.
<programlisting>
-(:person)-[:has]->(:account)
+(IS person)-[IS has]->(IS account)
</programlisting>
Multiple labels can also be matched, using <quote>or</quote> semantics:
<programlisting>
-(:person)-[:has]->(:account|creditcard)
+(IS person)-[IS has]->(IS account|creditcard)
</programlisting>
</para>
@@ -2890,11 +2884,11 @@ <title>Graph Patterns</title>
Recall that edges are directed. The other direction is also possible in a
path pattern, for example:
<programlisting>
-(:account)<-[:has]-(:person)
+(IS account)<-[IS has]-(IS person)
</programlisting>
It is also possible to match both directions:
<programlisting>
-(:person)-[:is_friend_of]-(:person)
+(IS person)-[IS is_friend_of]-(IS person)
</programlisting>
This has a meaning of <quote>or</quote>: An edge in either direction would
match.
@@ -2905,9 +2899,9 @@ <title>Graph Patterns</title>
then happens on the vertices.) For these cases, an abbreviated edge
pattern syntax is available that omits the brackets, for example:
<programlisting>
-(:person)->(:account)
-(:acount)<-(:person)
-(:person)-(:person)
+(IS person)->(IS account)
+(IS account)<-(IS person)
+(IS person)-(IS person)
</programlisting>
As is often the case, abbreviated syntax can make expressions more compact
but also sometimes harder to understand.
@@ -2922,13 +2916,13 @@ <title>Graph Patterns</title>
For example (assuming appropriate definitions of the property graph as
well as the underlying tables):
<programlisting>
-GRAPH_TABLE (mygraph MATCH (p:person)-[h:has]->(a:account)
+GRAPH_TABLE (mygraph MATCH (p IS person)-[h IS has]->(a IS account)
COLUMNS (p.name AS person_name, h.since AS has_account_since,
a.num AS account_number)
</programlisting>
<literal>WHERE</literal> clauses can be used inside element patterns to
filter matches:
<programlisting>
-(:person)-[:has]->(a:account WHERE a.type = 'savings')
+(IS person)-[IS has]->(a IS account WHERE a.type = 'savings')
</programlisting>
</para>
diff --git a/src/backend/catalog/sql_features.txt
b/src/backend/catalog/sql_features.txt
index 7cbaf492d23..626054cbcef 100644
--- a/src/backend/catalog/sql_features.txt
+++ b/src/backend/catalog/sql_features.txt
@@ -417,7 +417,7 @@ G803 MATCHNUM function NO
G810 IS BOUND predicate NO
G811 IS BOUND predicate: AS option NO
G820 BINDING_COUNT NO
-G830 Colon in 'is label' expression YES
+G830 Colon in 'is label' expression NO
G840 Path-ordered aggregates NO
G850 SQL/PGQ Information Schema views YES
G860 GET DIAGNOSTICS enhancements for SQL-property graphs
NO
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 0cad56576f0..b1171a315fb 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -18073,7 +18073,6 @@ opt_colid:
opt_is_label_expression:
IS label_expression { $$ = $2; }
- | ':' label_expression { $$ = $2; }
| /*EMPTY*/ { $$ = NULL; }
;
diff --git a/src/test/regress/expected/graph_table.out
b/src/test/regress/expected/graph_table.out
index ecac6096720..a4df7464d79 100644
--- a/src/test/regress/expected/graph_table.out
+++ b/src/test/regress/expected/graph_table.out
@@ -157,7 +157,7 @@ SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers
WHERE c.address = 'US')-
customer1
(1 row)
-SELECT * FROM GRAPH_TABLE (myshop MATCH
(c:customers)-[co:customer_orders]->(o:orders WHERE o.ordered_when = date
'2024-01-02') COLUMNS (c.name, c.address));
+SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[co IS
customer_orders]->(o IS orders WHERE o.ordered_when = date '2024-01-02')
COLUMNS (c.name, c.address));
name | address
-----------+---------
customer2 | CA
@@ -430,7 +430,7 @@ SELECT vn FROM all_vertices EXCEPT (SELECT svn FROM
all_connected_vertices UNION
(2 rows)
-- query all connections using a label shared by vertices and edges
-SELECT sn, cn, dn FROM GRAPH_TABLE (g1 MATCH (src : l1)-[conn : l1]->(dest :
l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn));
+SELECT sn, cn, dn FROM GRAPH_TABLE (g1 MATCH (src IS l1)-[conn IS l1]->(dest
IS l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn));
sn | cn | dn
-----+------+-----
v12 | e122 | v21
@@ -636,7 +636,7 @@ CREATE PROPERTY GRAPH g2
DESTINATION KEY (src_id) REFERENCES v3 (id)
LABEL l1 PROPERTIES ('g2.' || ename COLLATE "C" AS elname)
);
-SELECT sn, cn, dn FROM GRAPH_TABLE (g2 MATCH (src : l1)-[conn : l1]->(dest :
l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn)) ORDER BY
1, 2, 3;
+SELECT sn, cn, dn FROM GRAPH_TABLE (g2 MATCH (src IS l1)-[conn IS l1]->(dest
IS l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn)) ORDER
BY 1, 2, 3;
sn | cn | dn
--------+---------+--------
g2.v11 | g2.e121 | g2.v22
@@ -669,7 +669,7 @@ SELECT * FROM GRAPH_TABLE (g2 MATCH (a)-[b]->(a)-[b]->(a)
COLUMNS (a.elname AS s
-- prepared statements, any changes to the property graph should be reflected
in
-- the already prepared statements
-PREPARE cyclestmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH
(a:l1)->(b:l1)->(c:l1) WHERE a.elname = c.elname COLUMNS (a.elname AS self,
b.elname AS through)) ORDER BY self, through;
+PREPARE cyclestmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a IS l1)->(b IS
l1)->(c IS l1) WHERE a.elname = c.elname COLUMNS (a.elname AS self, b.elname AS
through)) ORDER BY self, through;
EXECUTE cyclestmt;
self | through
------+---------
@@ -743,7 +743,7 @@ ALTER PROPERTY GRAPH g1
DESTINATION KEY (src_id) REFERENCES v3 (id)
LABEL l2 PROPERTIES (ename AS elname)
);
-PREPARE loopstmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a)-[e:l2]->(a)
COLUMNS (e.elname AS loop)) ORDER BY loop COLLATE "C" ASC;
+PREPARE loopstmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a)-[e IS l2]->(a)
COLUMNS (e.elname AS loop)) ORDER BY loop COLLATE "C" ASC;
EXECUTE loopstmt;
loop
------
diff --git a/src/test/regress/expected/graph_table_rls.out
b/src/test/regress/expected/graph_table_rls.out
index e52beeeabd1..5cbd69dab7b 100644
--- a/src/test/regress/expected/graph_table_rls.out
+++ b/src/test/regress/expected/graph_table_rls.out
@@ -96,7 +96,7 @@ SET row_security TO ON;
-- to RLS policies, session user or RLS settings.
PREPARE graph_rls_query AS
SELECT * FROM GRAPH_TABLE (cabinet
- MATCH (u : users)-[a : accessed]->(d : document)
+ MATCH (u IS users)-[a IS accessed]->(d IS document)
WHERE f_leak(d.dtitle)
COLUMNS (u.pguser, a.aid, d.dtitle, d.dlevel))
ORDER BY 1, 2, 3, 4;
@@ -630,7 +630,7 @@ SET row_security TO ON;
-- Create a policy on document that references document itself via GRAPH_TABLE
CREATE POLICY pr ON document TO regress_graph_rls_dave
USING (EXISTS (SELECT 1 FROM GRAPH_TABLE (cabinet
- MATCH (u : users)-[a : accessed]->(d : document)
+ MATCH (u IS users)-[a IS accessed]->(d IS document)
WHERE u.pguser = current_user
COLUMNS (a.aid))));
SET SESSION AUTHORIZATION regress_graph_rls_dave;
diff --git a/src/test/regress/expected/privileges.out
b/src/test/regress/expected/privileges.out
index 828357ab451..2114b1e354e 100644
--- a/src/test/regress/expected/privileges.out
+++ b/src/test/regress/expected/privileges.out
@@ -3090,49 +3090,49 @@ create property graph ptg1
default label
label ltv properties (col1 as ltvk));
-- select privileges on property graph as well as table
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- ok
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- ok
value
-------
(0 rows)
grant select on ptg1 to regress_priv_user2;
set session role regress_priv_user2;
-select * from graph_table (ptg1 match ( : atest1) COLUMNS (1 as value)) limit
0; -- ok
+select * from graph_table (ptg1 match (is atest1) COLUMNS (1 as value)) limit
0; -- ok
value
-------
(0 rows)
-- select privileges on property graph but not table
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- fails
ERROR: permission denied for table atest5
-select * from graph_table (ptg1 match ( : lttc) COLUMNS (1 as value)) limit 0;
-- fails
+select * from graph_table (ptg1 match (is lttc) COLUMNS (1 as value)) limit 0;
-- fails
ERROR: permission denied for table atest5
set session role regress_priv_user3;
-- select privileges on table but not property graph
-select * from graph_table (ptg1 match ( : atest1) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is atest1) COLUMNS (1 as value)) limit
0; -- fails
ERROR: permission denied for property graph ptg1
-- select privileges on neither
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- fails
ERROR: permission denied for property graph ptg1
-- column privileges
set session role regress_priv_user1;
-select * from graph_table (ptg1 match (v : lttc) COLUMNS (v.lttck)) limit 0;
-- ok
+select * from graph_table (ptg1 match (v is lttc) COLUMNS (v.lttck)) limit 0;
-- ok
lttck
-------
(0 rows)
grant select on ptg1 to regress_priv_user4;
set session role regress_priv_user4;
-select * from graph_table (ptg1 match (a : atest5) COLUMNS (a.four)) limit 0;
-- ok
+select * from graph_table (ptg1 match (a is atest5) COLUMNS (a.four)) limit 0;
-- ok
four
------
(0 rows)
-select * from graph_table (ptg1 match (v : lttc) COLUMNS (v.lttck)) limit 0;
-- fail
+select * from graph_table (ptg1 match (v is lttc) COLUMNS (v.lttck)) limit 0;
-- fail
ERROR: permission denied for table atest5
-- access property graph through security definer view
set session role regress_priv_user4;
-create view atpgv1 as select * from graph_table (ptg1 match ( : atest1)
COLUMNS (1 as value)) limit 0;
+create view atpgv1 as select * from graph_table (ptg1 match (is atest1)
COLUMNS (1 as value)) limit 0;
grant select on atpgv1 to regress_priv_user3;
select * from atpgv1; -- ok
value
@@ -3146,7 +3146,7 @@ select * from atpgv1; -- ok
(0 rows)
set session role regress_priv_user4;
-create view atpgv2 as select * from graph_table (ptg1 match (v : ltv) COLUMNS
(v.ltvk)) limit 0;
+create view atpgv2 as select * from graph_table (ptg1 match (v is ltv) COLUMNS
(v.ltvk)) limit 0;
-- though the session user is the owner of the view and also has access to the
-- property graph, it does not have access to a table referenced in the graph
-- pattern
diff --git a/src/test/regress/sql/graph_table.sql
b/src/test/regress/sql/graph_table.sql
index 412da394aab..7521c3e5c1d 100644
--- a/src/test/regress/sql/graph_table.sql
+++ b/src/test/regress/sql/graph_table.sql
@@ -133,7 +133,7 @@ CREATE PROPERTY GRAPH myshop
SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers WHERE c.address =
'US')-[IS customer_orders]->(o IS orders) COLUMNS (c.name));
-- graph element specification without label or variable
SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers WHERE c.address =
'US')-[]->(o IS orders) COLUMNS (c.name AS customer_name));
-SELECT * FROM GRAPH_TABLE (myshop MATCH
(c:customers)-[co:customer_orders]->(o:orders WHERE o.ordered_when = date
'2024-01-02') COLUMNS (c.name, c.address));
+SELECT * FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[co IS
customer_orders]->(o IS orders WHERE o.ordered_when = date '2024-01-02')
COLUMNS (c.name, c.address));
SELECT * FROM GRAPH_TABLE (myshop MATCH (o IS orders)-[IS customer_orders]->(c
IS customers) COLUMNS (c.name, o.ordered_when));
SELECT * FROM GRAPH_TABLE (myshop MATCH (o IS orders)<-[IS customer_orders]-(c
IS customers) COLUMNS (c.name, o.ordered_when));
-- spaces around pattern operators
@@ -292,7 +292,7 @@ CREATE PROPERTY GRAPH g1
all_vertices AS (SELECT vn FROM GRAPH_TABLE (g1 MATCH (vertex) COLUMNS
(vertex.vname AS vn)))
SELECT vn FROM all_vertices EXCEPT (SELECT svn FROM all_connected_vertices
UNION SELECT dvn FROM all_connected_vertices);
-- query all connections using a label shared by vertices and edges
-SELECT sn, cn, dn FROM GRAPH_TABLE (g1 MATCH (src : l1)-[conn : l1]->(dest :
l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn));
+SELECT sn, cn, dn FROM GRAPH_TABLE (g1 MATCH (src IS l1)-[conn IS l1]->(dest
IS l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn));
-- Tests for cyclic path patterns
CREATE TABLE e2_1 (
@@ -405,14 +405,14 @@ CREATE PROPERTY GRAPH g2
DESTINATION KEY (src_id) REFERENCES v3 (id)
LABEL l1 PROPERTIES ('g2.' || ename COLLATE "C" AS elname)
);
-SELECT sn, cn, dn FROM GRAPH_TABLE (g2 MATCH (src : l1)-[conn : l1]->(dest :
l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn)) ORDER BY
1, 2, 3;
+SELECT sn, cn, dn FROM GRAPH_TABLE (g2 MATCH (src IS l1)-[conn IS l1]->(dest
IS l1) COLUMNS (src.elname AS sn, conn.elname AS cn, dest.elname AS dn)) ORDER
BY 1, 2, 3;
SELECT * FROM GRAPH_TABLE (g2 MATCH (a)-[b WHERE b.elname >
'g2.E331']->(a)-[b]->(a) COLUMNS (a.elname AS self, b.elname AS loop_name));
SELECT * FROM GRAPH_TABLE (g2 MATCH (a)-[b]->(a)-[b]->(a) WHERE b.elname >
'g2.E331' COLUMNS (a.elname AS self, b.elname AS loop_name));
SELECT * FROM GRAPH_TABLE (g2 MATCH (a)-[b]->(a)-[b]->(a) COLUMNS (a.elname AS
self, b.elname AS loop_name)) WHERE loop_name > 'g2.E331';
-- prepared statements, any changes to the property graph should be reflected
in
-- the already prepared statements
-PREPARE cyclestmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH
(a:l1)->(b:l1)->(c:l1) WHERE a.elname = c.elname COLUMNS (a.elname AS self,
b.elname AS through)) ORDER BY self, through;
+PREPARE cyclestmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a IS l1)->(b IS
l1)->(c IS l1) WHERE a.elname = c.elname COLUMNS (a.elname AS self, b.elname AS
through)) ORDER BY self, through;
EXECUTE cyclestmt;
ALTER PROPERTY GRAPH g1 DROP EDGE TABLES (e3_2, e3_3);
EXECUTE cyclestmt;
@@ -436,7 +436,7 @@ CREATE PROPERTY GRAPH g2
DESTINATION KEY (src_id) REFERENCES v3 (id)
LABEL l2 PROPERTIES (ename AS elname)
);
-PREPARE loopstmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a)-[e:l2]->(a)
COLUMNS (e.elname AS loop)) ORDER BY loop COLLATE "C" ASC;
+PREPARE loopstmt AS SELECT * FROM GRAPH_TABLE (g1 MATCH (a)-[e IS l2]->(a)
COLUMNS (e.elname AS loop)) ORDER BY loop COLLATE "C" ASC;
EXECUTE loopstmt;
ALTER PROPERTY GRAPH g1 ALTER EDGE TABLE e3_3 ALTER LABEL l2 DROP PROPERTIES
(elname);
EXECUTE loopstmt; -- error
diff --git a/src/test/regress/sql/graph_table_rls.sql
b/src/test/regress/sql/graph_table_rls.sql
index 3644b6e192f..044bc27ce9f 100644
--- a/src/test/regress/sql/graph_table_rls.sql
+++ b/src/test/regress/sql/graph_table_rls.sql
@@ -112,7 +112,7 @@ CREATE POLICY p4 ON document_people AS PERMISSIVE TO
regress_graph_rls_group2
-- to RLS policies, session user or RLS settings.
PREPARE graph_rls_query AS
SELECT * FROM GRAPH_TABLE (cabinet
- MATCH (u : users)-[a : accessed]->(d : document)
+ MATCH (u IS users)-[a IS accessed]->(d IS document)
WHERE f_leak(d.dtitle)
COLUMNS (u.pguser, a.aid, d.dtitle, d.dlevel))
ORDER BY 1, 2, 3, 4;
@@ -312,7 +312,7 @@ CREATE PROPERTY GRAPH cabinet
-- Create a policy on document that references document itself via GRAPH_TABLE
CREATE POLICY pr ON document TO regress_graph_rls_dave
USING (EXISTS (SELECT 1 FROM GRAPH_TABLE (cabinet
- MATCH (u : users)-[a : accessed]->(d : document)
+ MATCH (u IS users)-[a IS accessed]->(d IS document)
WHERE u.pguser = current_user
COLUMNS (a.aid))));
SET SESSION AUTHORIZATION regress_graph_rls_dave;
diff --git a/src/test/regress/sql/privileges.sql
b/src/test/regress/sql/privileges.sql
index f3a438d2732..c7fdfb691ae 100644
--- a/src/test/regress/sql/privileges.sql
+++ b/src/test/regress/sql/privileges.sql
@@ -1815,34 +1815,34 @@ CREATE SCHEMA testns;
default label
label ltv properties (col1 as ltvk));
-- select privileges on property graph as well as table
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- ok
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- ok
grant select on ptg1 to regress_priv_user2;
set session role regress_priv_user2;
-select * from graph_table (ptg1 match ( : atest1) COLUMNS (1 as value)) limit
0; -- ok
+select * from graph_table (ptg1 match (is atest1) COLUMNS (1 as value)) limit
0; -- ok
-- select privileges on property graph but not table
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- fails
-select * from graph_table (ptg1 match ( : lttc) COLUMNS (1 as value)) limit 0;
-- fails
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is lttc) COLUMNS (1 as value)) limit 0;
-- fails
set session role regress_priv_user3;
-- select privileges on table but not property graph
-select * from graph_table (ptg1 match ( : atest1) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is atest1) COLUMNS (1 as value)) limit
0; -- fails
-- select privileges on neither
-select * from graph_table (ptg1 match ( : atest5) COLUMNS (1 as value)) limit
0; -- fails
+select * from graph_table (ptg1 match (is atest5) COLUMNS (1 as value)) limit
0; -- fails
-- column privileges
set session role regress_priv_user1;
-select * from graph_table (ptg1 match (v : lttc) COLUMNS (v.lttck)) limit 0;
-- ok
+select * from graph_table (ptg1 match (v is lttc) COLUMNS (v.lttck)) limit 0;
-- ok
grant select on ptg1 to regress_priv_user4;
set session role regress_priv_user4;
-select * from graph_table (ptg1 match (a : atest5) COLUMNS (a.four)) limit 0;
-- ok
-select * from graph_table (ptg1 match (v : lttc) COLUMNS (v.lttck)) limit 0;
-- fail
+select * from graph_table (ptg1 match (a is atest5) COLUMNS (a.four)) limit 0;
-- ok
+select * from graph_table (ptg1 match (v is lttc) COLUMNS (v.lttck)) limit 0;
-- fail
-- access property graph through security definer view
set session role regress_priv_user4;
-create view atpgv1 as select * from graph_table (ptg1 match ( : atest1)
COLUMNS (1 as value)) limit 0;
+create view atpgv1 as select * from graph_table (ptg1 match (is atest1)
COLUMNS (1 as value)) limit 0;
grant select on atpgv1 to regress_priv_user3;
select * from atpgv1; -- ok
set session role regress_priv_user3;
select * from atpgv1; -- ok
set session role regress_priv_user4;
-create view atpgv2 as select * from graph_table (ptg1 match (v : ltv) COLUMNS
(v.ltvk)) limit 0;
+create view atpgv2 as select * from graph_table (ptg1 match (v is ltv) COLUMNS
(v.ltvk)) limit 0;
-- though the session user is the owner of the view and also has access to the
-- property graph, it does not have access to a table referenced in the graph
-- pattern
--
2.52.0
