Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some typos and make small stylistic improvements

  2. Cleanup users and roles in graph_table_rls test

  3. Dump labels in reproducible order

  4. SQL Property Graph Queries (SQL/PGQ)

  5. Factor out constructSetOpTargetlist() from transformSetOperationTree()

  6. Sort out table_open vs. relation_open in rewriter

  7. Rename grammar nonterminal to simplify reuse

  8. Make ecpg parse.pl more robust with braces

  9. Don't lock partitions pruned by initial pruning

  10. Remove pg_regex_collation

  11. Use auxv to check for CRC32 instructions on ARM.

  12. Fix inappropriate uses of atol()

  13. Remove unnecessary array object_classes[] in dependency.c

  1. SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2024-02-16T14:53:11Z

    Here is a prototype implementation of SQL property graph queries
(SQL/PGQ), following SQL:2023.  This was talked about briefly at the
FOSDEM developer meeting, and a few people were interested, so I
wrapped up what I had in progress into a presentable form.

There is some documentation to get started in doc/src/sgml/ddl.sgml
and doc/src/sgml/queries.sgml.

To learn more about this facility, here are some external resources:

* An article about a competing product:
   https://oracle-base.com/articles/23c/sql-property-graphs-and-sql-pgq-23c
   (All the queries in the article work, except the ones using
   vertex_id() and edge_id(), which are non-standard, and the JSON
   examples at the end, which require some of the in-progress JSON
   functionality for PostgreSQL.)

* An academic paper related to another competing product:
   https://www.cidrdb.org/cidr2023/papers/p66-wolde.pdf (The main part
   of this paper discusses advanced functionality that my patch doesn't
   have.)

* A 2019 presentation about graph databases:
   https://www.pgcon.org/2019/schedule/events/1300.en.html (There is
   also a video.)

* (Vik has a recent presentation "Property Graphs: When the Relational
   Model Is Not Enough", but I haven't found the content posted
   online.)

The patch is quite fragile, and treading outside the tested paths will
likely lead to grave misbehavior.  Use with caution.  But I feel that
the general structure is ok, and we just need to fill in the
proverbial few thousand lines of code in the designated areas.

  2. Re: SQL Property Graph Queries (SQL/PGQ)

    Andres Freund <andres@anarazel.de> — 2024-02-16T19:23:01Z

    Hi,

On 2024-02-16 15:53:11 +0100, Peter Eisentraut wrote:
> The patch is quite fragile, and treading outside the tested paths will
> likely lead to grave misbehavior.  Use with caution.  But I feel that
> the general structure is ok, and we just need to fill in the
> proverbial few thousand lines of code in the designated areas.

One aspect that I m concerned with structurally is that the transformation,
from property graph queries to something postgres understands, is done via the
rewrite system. I doubt that that is a good idea. For one it bars the planner
from making plans that benefit from the graph query formulation. But more
importantly, we IMO should reduce usage of the rewrite system, not increase
it.

Greetings,

Andres Freund

  3. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2024-02-23T16:15:41Z

    On 16.02.24 20:23, Andres Freund wrote:
> One aspect that I m concerned with structurally is that the transformation,
> from property graph queries to something postgres understands, is done via the
> rewrite system. I doubt that that is a good idea. For one it bars the planner
> from making plans that benefit from the graph query formulation. But more
> importantly, we IMO should reduce usage of the rewrite system, not increase
> it.

PGQ is meant to be implemented like that, like views expanding to joins 
and unions.  This is what I have gathered during the specification 
process, and from other implementations, and from academics.  There are 
certainly other ways to combine relational and graph database stuff, 
like with native graph storage and specialized execution support, but 
this is not that, and to some extent PGQ was created to supplant those 
other approaches.

Many people will agree that the rewriter is sort of weird and archaic at 
this point.  But I'm not aware of any plans or proposals to do anything 
about it.  As long as the view expansion takes place there, it makes 
sense to align with that.  For example, all the view security stuff 
(privileges, security barriers, etc.) will eventually need to be 
considered, and it would make sense to do that in a consistent way.  So 
for now, I'm working with what we have, but let's see where it goes.

(Note to self: Check that graph inside view inside graph inside view ... 
works.)

  4. Re: SQL Property Graph Queries (SQL/PGQ)

    Tomas Vondra <tomas.vondra@enterprisedb.com> — 2024-02-23T17:37:59Z

    On 2/23/24 17:15, Peter Eisentraut wrote:
> On 16.02.24 20:23, Andres Freund wrote:
>> One aspect that I m concerned with structurally is that the
>> transformation,
>> from property graph queries to something postgres understands, is done
>> via the
>> rewrite system. I doubt that that is a good idea. For one it bars the
>> planner
>> from making plans that benefit from the graph query formulation. But more
>> importantly, we IMO should reduce usage of the rewrite system, not
>> increase
>> it.
> 
> PGQ is meant to be implemented like that, like views expanding to joins
> and unions.  This is what I have gathered during the specification
> process, and from other implementations, and from academics.  There are
> certainly other ways to combine relational and graph database stuff,
> like with native graph storage and specialized execution support, but
> this is not that, and to some extent PGQ was created to supplant those
> other approaches.
> 

I understand PGQ was meant to be implemented as a bit of a "syntactic
sugar" on top of relations, instead of inventing some completely new
ways to store/query graph data.

But does that really mean it needs to be translated to relations this
early / in rewriter? I haven't thought about it very deeply, but won't
that discard useful information about semantics of the query, which
might be useful when planning/executing the query?

I've somehow imagined we'd be able to invent some new index types, or
utilize some other type of auxiliary structure, maybe some special
executor node, but it seems harder without this extra info ...

> Many people will agree that the rewriter is sort of weird and archaic at
> this point.  But I'm not aware of any plans or proposals to do anything
> about it.  As long as the view expansion takes place there, it makes
> sense to align with that.  For example, all the view security stuff
> (privileges, security barriers, etc.) will eventually need to be
> considered, and it would make sense to do that in a consistent way.  So
> for now, I'm working with what we have, but let's see where it goes.
> 
> (Note to self: Check that graph inside view inside graph inside view ...
> works.)
> 

AFAIK the "policy" regarding rewriter was that we don't want to use it
for user stuff (e.g. people using it for partitioning), but I'm not sure
about internal stuff.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

  5. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-02-26T06:16:11Z

    On Fri, Feb 23, 2024 at 11:08 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 2/23/24 17:15, Peter Eisentraut wrote:
> > On 16.02.24 20:23, Andres Freund wrote:
> >> One aspect that I m concerned with structurally is that the
> >> transformation,
> >> from property graph queries to something postgres understands, is done
> >> via the
> >> rewrite system. I doubt that that is a good idea. For one it bars the
> >> planner
> >> from making plans that benefit from the graph query formulation. But more
> >> importantly, we IMO should reduce usage of the rewrite system, not
> >> increase
> >> it.
> >
> > PGQ is meant to be implemented like that, like views expanding to joins
> > and unions.  This is what I have gathered during the specification
> > process, and from other implementations, and from academics.  There are
> > certainly other ways to combine relational and graph database stuff,
> > like with native graph storage and specialized execution support, but
> > this is not that, and to some extent PGQ was created to supplant those
> > other approaches.
> >
>
> I understand PGQ was meant to be implemented as a bit of a "syntactic
> sugar" on top of relations, instead of inventing some completely new
> ways to store/query graph data.
>
> But does that really mean it needs to be translated to relations this
> early / in rewriter? I haven't thought about it very deeply, but won't
> that discard useful information about semantics of the query, which
> might be useful when planning/executing the query?
>
> I've somehow imagined we'd be able to invent some new index types, or
> utilize some other type of auxiliary structure, maybe some special
> executor node, but it seems harder without this extra info ...

I am yet to look at the implementation but ...
1. If there are optimizations that improve performance of some path
patterns, they are likely to improve the performance of joins used to
implement those. In such cases, loosing some information might be ok.
2. Explicit graph annotatiion might help to automate some things like
creating indexes automatically on columns that appear in specific
patterns OR create extended statistics automatically on the columns
participating in specific patterns. OR interpreting statistics/costing
in differently than normal query execution. Those kind of things will
require retaining annotations in views, planner/execution trees etc.
3. There are some things like aggregates/operations on paths which
might require stuff like new execution nodes. But I am not sure we
have reached that stage yet.

There might be things we may not see right now in the standard e.g.
indexes on graph properties. For those mapping the graph objects unto
database objects might prove useful. That goes back to Peter's comment
--- quote
As long as the view expansion takes place there, it makes
sense to align with that.  For example, all the view security stuff
(privileges, security barriers, etc.) will eventually need to be
considered, and it would make sense to do that in a consistent way.
--- unquote

-- 
Best Wishes,
Ashutosh Bapat

  6. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-03-05T12:08:30Z

    Patch conflicted with changes in ef5e2e90859a39efdd3a78e528c544b585295a78.
Attached patch with the conflict resolved.

-- 
Best Wishes,
Ashutosh Bapat

  7. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2024-06-27T12:31:00Z

    Here is a new version of this patch.  I have been working together with 
Ashutosh on this.  While the version 0 was more of a fragile demo, this 
version 1 has a fairly complete minimal feature set and should be useful 
for playing around with.  We do have a long list of various internal 
bits that still need to be fixed or revised or looked at again, so there 
is by no means a claim that everything is completed.

Documentation to get started is included (ddl.sgml and queries.sgml). 
(Of course, feedback on the getting-started documentation would be most 
welcome.)

  8. Re: SQL Property Graph Queries (SQL/PGQ)

    Florents Tselai <florents.tselai@gmail.com> — 2024-07-04T08:19:46Z

    In the ddl.sgml, I’d swap the first two paragraphs.
I find the first one a bit confusing as-is. As far as I can tell, it’s an implementation detail.
The first paragraph should answer, “I have some data modeled as a graph G=(V, E). Can Postgres help me?”.

Then, introducing property graphs makes more sense. 

I'd also use the examples and fake data in `graph_table.sql` in ddl/queries.sgml).
I was bummed that that copy-pasting didn't work as is.
I’d keep explaining how a graph query translates to a relational one later in the page.

As for the implementation, I can’t have an opinion yet,
but for those not familiar, Apache Age uses a slightly different approach
that mimics jsonpath (parses a sublanguage expression into an internal execution engine etc.).
However, the standard requires mapping this to the relational model, which makes sense for core Postgres.


> On 27 Jun 2024, at 3:31 PM, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
> Here is a new version of this patch.  I have been working together with Ashutosh on this.  While the version 0 was more of a fragile demo, this version 1 has a fairly complete minimal feature set and should be useful for playing around with.  We do have a long list of various internal bits that still need to be fixed or revised or looked at again, so there is by no means a claim that everything is completed.
> 
> Documentation to get started is included (ddl.sgml and queries.sgml). (Of course, feedback on the getting-started documentation would be most welcome.)
> <v1-0001-WIP-SQL-Property-Graph-Queries-SQL-PGQ.patch>

  9. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-07-08T13:37:48Z

    On Thu, Jun 27, 2024 at 6:01 PM Peter Eisentraut <peter@eisentraut.org>
wrote:

> Here is a new version of this patch.  I have been working together with
> Ashutosh on this.  While the version 0 was more of a fragile demo, this
> version 1 has a fairly complete minimal feature set and should be useful
> for playing around with.  We do have a long list of various internal
> bits that still need to be fixed or revised or looked at again, so there
> is by no means a claim that everything is completed.
>

PFA the patchset fixing compilation error reported by CI bot.
0001 - same as previous one
0002 - fixes compilation error
0003 - adds support for WHERE clause in graph pattern missing in the first
patch.

-- 
Best Wishes,
Ashutosh Bapat

  10. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-07-17T05:34:48Z

    On Mon, Jul 8, 2024 at 7:07 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
>
>
> On Thu, Jun 27, 2024 at 6:01 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> Here is a new version of this patch.  I have been working together with
>> Ashutosh on this.  While the version 0 was more of a fragile demo, this
>> version 1 has a fairly complete minimal feature set and should be useful
>> for playing around with.  We do have a long list of various internal
>> bits that still need to be fixed or revised or looked at again, so there
>> is by no means a claim that everything is completed.
>
>
> PFA the patchset fixing compilation error reported by CI bot.
> 0001 - same as previous one
> 0002 - fixes compilation error
> 0003 - adds support for WHERE clause in graph pattern missing in the first patch.
>

There's a test failure reported by CI. Property graph related tests
are failing when regression is run from perl tests. The failure is
reported only on Free BSD. I have added one patch in the series which
will help narrow the failure. The patch changes the code to report the
location of an error reported when handling implicit properties or
labels.
0001 - same as previous one
0002 - fixes pgperltidy complaints
0003 - fixes compilation failure
0004 - same as 0003 in previous set
0005 - patch to report parse location of error



-- 
Best Wishes,
Ashutosh Bapat

  11. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-07-22T12:01:42Z

    On Wed, Jul 17, 2024 at 11:04 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Mon, Jul 8, 2024 at 7:07 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jun 27, 2024 at 6:01 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >>
> >> Here is a new version of this patch.  I have been working together with
> >> Ashutosh on this.  While the version 0 was more of a fragile demo, this
> >> version 1 has a fairly complete minimal feature set and should be useful
> >> for playing around with.  We do have a long list of various internal
> >> bits that still need to be fixed or revised or looked at again, so there
> >> is by no means a claim that everything is completed.
> >
> >
> > PFA the patchset fixing compilation error reported by CI bot.
> > 0001 - same as previous one
> > 0002 - fixes compilation error
> > 0003 - adds support for WHERE clause in graph pattern missing in the first patch.
> >
>
> There's a test failure reported by CI. Property graph related tests
> are failing when regression is run from perl tests. The failure is
> reported only on Free BSD.

I thought it's related to FreeBSD but the bug could be observed
anywhere with -DRELCACHE_FORCE_RELEASE. It's also reported indirectly
by valgrind.

When infering properties of an element from the underlying table's
attributes, the attribute name pointed to the memory in the heap tuple
of pg_attribute row. Thus when the tuple was released, it pointed to a
garbage instead of actual column name resulting in column not found
error.

Attached set of patches with an additional patch to fix the bug.

0001 - same as previous one
0002 - fixes pgperltidy complaints
0003 - fixes compilation failure
0004 - fixes issue seen on CI
0005 - adds support for WHERE clause in graph pattern missing in the
first patch.

Once reviewed, patches 0002 to 0005 should be merged into 0001.

-- 
Best Wishes,
Ashutosh Bapat

  12. Re: SQL Property Graph Queries (SQL/PGQ)

    Imran Zaheer <imran.zhir@gmail.com> — 2024-08-04T07:02:07Z

    Hi
I am attaching a new patch for a minor feature addition.

- Adding support for 'Labels and properties: EXCEPT list'

Please let me know if something is missing.

Thanks and Regards
Imran Zaheer

On Mon, Jul 22, 2024 at 9:02 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Wed, Jul 17, 2024 at 11:04 AM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Mon, Jul 8, 2024 at 7:07 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > >
> > >
> > > On Thu, Jun 27, 2024 at 6:01 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> > >>
> > >> Here is a new version of this patch.  I have been working together with
> > >> Ashutosh on this.  While the version 0 was more of a fragile demo, this
> > >> version 1 has a fairly complete minimal feature set and should be useful
> > >> for playing around with.  We do have a long list of various internal
> > >> bits that still need to be fixed or revised or looked at again, so there
> > >> is by no means a claim that everything is completed.
> > >
> > >
> > > PFA the patchset fixing compilation error reported by CI bot.
> > > 0001 - same as previous one
> > > 0002 - fixes compilation error
> > > 0003 - adds support for WHERE clause in graph pattern missing in the first patch.
> > >
> >
> > There's a test failure reported by CI. Property graph related tests
> > are failing when regression is run from perl tests. The failure is
> > reported only on Free BSD.
>
> I thought it's related to FreeBSD but the bug could be observed
> anywhere with -DRELCACHE_FORCE_RELEASE. It's also reported indirectly
> by valgrind.
>
> When infering properties of an element from the underlying table's
> attributes, the attribute name pointed to the memory in the heap tuple
> of pg_attribute row. Thus when the tuple was released, it pointed to a
> garbage instead of actual column name resulting in column not found
> error.
>
> Attached set of patches with an additional patch to fix the bug.
>
> 0001 - same as previous one
> 0002 - fixes pgperltidy complaints
> 0003 - fixes compilation failure
> 0004 - fixes issue seen on CI
> 0005 - adds support for WHERE clause in graph pattern missing in the
> first patch.
>
> Once reviewed, patches 0002 to 0005 should be merged into 0001.
>
> --
> Best Wishes,
> Ashutosh Bapat

  13. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-08-05T12:41:20Z

    On Mon, Jul 22, 2024 at 5:31 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>

I found that the patches do not support cyclic paths correctly. A
cyclic path pattern is a path patterns where an element pattern
variable repeats e.g. (a)->(b)->(a). In such a path pattern the
element patterns with the same variable indicate the same element in
the path. In the given example (a) specifies that the path should
start and end with the same vertex. Patch 0006 supports cyclic path
patterns.

Elements which share the variable name should have the same element
type. The element patterns sharing the same variable name should have
same label expression. They may be constrained by different conditions
which are finally ANDed since they all represent the same element. The
patch creates a separate abstraction "path_factor" which combines all
the GraphElementPatterns into one element pattern. SQL/PGQ standard
uses path_factor for such an entity, so I chose that as the structure
name. But suggestions are welcome.

A path_factor is further expanded into a list of path_element objects
each representing a vertex or edge table that satisfies the label
expression in GraphElementPattern. In the previous patch set, the
consecutive elements were considered to be connected to each other.
Cyclic paths change that. For example, in path pattern (a)->(b)->(a),
(b) is connected to the first element on both sides (forming a cycle)
instead of first and third element. Patch 0006 has code changes to
appropriately link the elements. As a side effect, I have eliminated
the confusion between variables with name gep and gpe.

While it's easy to imagine a repeated vertex pattern, a repeated edge
pattern is slightly complex. An edge connects only two vertices, and
thus a repeated edge pattern constrains the adjacent vertex patterns
even if they have different variable names. Such patterns are not
supported. E.g. (a)-[b]->(c)-[b]->(d) would mean that (d) and (a)
represent the same vertex even if the variable names are different.
Such patterns are not supported for now. But (a)-[b]->(a)-[b]->(a) OR
(a)-[b]->(c)<-[b]-(a) are supported since the vertices adjacent to
repeated edges are constrained by the variable name anyway.

The patch also changes many foreach() to use foreach_* macros as appropriate.

> 0001 - same as previous one
> 0002 - fixes pgperltidy complaints
> 0003 - fixes compilation failure
> 0004 - fixes issue seen on CI
> 0005 - adds support for WHERE clause in graph pattern missing in the
> first patch.
0006 - adds full support for cyclic path patterns

Once reviewed, patches 0002 to 0006 should be merged into 0001.

-- 
Best Wishes,
Ashutosh Bapat

  14. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-08-05T13:12:46Z

    Hi Imran,

On Sun, Aug 4, 2024 at 12:32 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
>
> Hi
> I am attaching a new patch for a minor feature addition.
>
> - Adding support for 'Labels and properties: EXCEPT list'

Do you intend to support EXCEPT in the label expression as well or
just properties?

>
> Please let me know if something is missing.

I think the code changes are in the right place. I didn't review the
patch thoroughly. But here are some comments and some advice.

Please do not top-post on hackers.

Always sent the whole patchset. Otherwise, CI bot gets confused. It
doesn't pick up patchset from the previous emails.

About the functionality: It's not clear to me whether an EXCEPT should
be applicable only at the time of property graph creation or it should
be applicable always. I.e. when a property graph is dumped, should it
have EXCEPT in it or have a list of columns surviving except list?
What if a column in except list is dropped after creating a property
graph?

Some comments on the code
1. You could use list_member() in insert_property_records() to check
whether a given column is in the list of exceptions after you have
enveloped in String node.
2. The SELECT with GRAPH_TABLE queries are tested in graph_table.sql.
We don't include those in create_property_graph.sql
3. Instead of creating a new property graph in the test, you may
modify one of the existing property graphs to have a label with except
list and then query it.

We are aiming a minimal set of features in the first version. I will
let Peter E. decide whether to consider this as minimal set feature or
not. The feature looks useful to me.

-- 
Best Wishes,
Ashutosh Bapat

  15. Re: SQL Property Graph Queries (SQL/PGQ)

    Imran Zaheer <imran.zhir@gmail.com> — 2024-08-10T09:21:43Z

    Hi Ashutosh,

Thanks for the feedback.

> Do you intend to support EXCEPT in the label expression as well or
> just properties?
>

I only implemented it for the properties because I couldn't find any
example for Label expression using EXCEPT clause. So I thought it was
only meant to be for the properties.
But if you can confirm that we do use EXCEPT clauses with label
expressions as well then I can try supporting that too.

>
> Please do not top-post on hackers.
>
> Always sent the whole patchset. Otherwise, CI bot gets confused. It
> doesn't pick up patchset from the previous emails.
>
Okay, I will take care of that.

> About the functionality: It's not clear to me whether an EXCEPT should
> be applicable only at the time of property graph creation or it should
> be applicable always. I.e. when a property graph is dumped, should it
> have EXCEPT in it or have a list of columns surviving except list?
> What if a column in except list is dropped after creating a property
> graph?
>

I did some testing on that,  for now we are just dumping the columns
surviving the except list.
If an exceptional table column is deleted afterwards it doesn't show
any effect on the graph. I also tested this scenario with duckdb pgq
extension [1], deleting the col doesn't affect the graph.

> Some comments on the code

I am attaching a new patch after trying to fix according to you comments

> 1. You could use list_member() in insert_property_records() to check
> whether a given column is in the list of exceptions after you have
> enveloped in String node.

* I have changed to code to use list_member(), but I have to make
ResTarget->name from `pstrdup(NameStr(att->attname));` to `NULL`
We are using `xml_attribute_list` for our columns list and while
making this list in gram.y we are assigning `rt->name` as NULL [2],
this causes list_member() func to fail while comparing except_list
nodes. That's why I am changing rt->name from string value to NULL in
propgraphcmds.c in this patch.

* Also, in order to use list_member() func I have to add a separate
for loop to iterate through the exceptional columns to generate the
error message if col is not valid. My question is, is it ok to use two
separate for loops (one to check except cols validity &
other(list_memeber) to check existence of scanned col in except list).
In the previous patch I was using single for loop to validate both
things.

> 2. The SELECT with GRAPH_TABLE queries are tested in graph_table.sql.
> We don't include those in create_property_graph.sql

* I have moved the graph_table queries from create_property_graph.sql
to graph_table.sql.
* But in graph_table.sql I didn't use the existing graphs because
those graphs and tables look like there for some specific test
scenario, so I created my separate graph and table for my test
scenario. I didn't drop the graph and the table as we will be dropping
the schema at the end but Peter E has this comment "-- leave for
pg_upgrade/pg_dump tests".

> 3. Instead of creating a new property graph in the test, you may
> modify one of the existing property graphs to have a label with except
> list and then query it.
>

* I have modified the graphs in create_property_graph.sql in order to
test except list cols in the alter command and create graph command.

> We are aiming a minimal set of features in the first version. I will
> let Peter E. decide whether to consider this as minimal set feature or
> not. The feature looks useful to me.

Thanks if you find this patch useful. I am attaching the modified patch.

> 0001 - same as previous one
> 0002 - fixes pgperltidy complaints
> 0003 - fixes compilation failure
> 0004 - fixes issue seen on CI
> 0005 - adds support for WHERE clause in graph pattern missing in the
> first patch.
> 0006 - adds full support for cyclic path patterns

0007 - adds support for except cols list in graph properties

Thanks
Imran Zaheer

[1]: https://github.com/cwida/duckpgq-extension
[2]: https://github.com/postgres/postgres/blob/f5a1311fccd2ed24a9fb42aa47a17d1df7126039/src/backend/parser/gram.y#L16166

  16. Re: SQL Property Graph Queries (SQL/PGQ)

    Ajay Pal <ajay.pal.k@gmail.com> — 2024-08-13T09:52:43Z

    Hello,

With the attached patch found below error when try to use "Any
directed edge" syntax.

postgres=# SELECT * FROM GRAPH_TABLE (students_graph
postgres(#   MATCH
postgres(#   (a IS person )  - [] - (b IS person)
postgres(#   COLUMNS (a.name AS person_a, b.name AS person_b)
postgres(# );
ERROR:  unsupported element pattern kind: undirected edge

If this syntax is supported then should behave as below,

PERSON_A   PERSON_B
---------- ----------
Bob    John
John    Mary
Alice    Mary
Mary    Bob
Mary    John
Bob    Mary
John    Bob
Mary    Alice

8 rows selected.

Attaching the sql file for reference.

Thanks
Ajay

On Sat, Aug 10, 2024 at 2:52 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
>
> Hi Ashutosh,
>
> Thanks for the feedback.
>
> > Do you intend to support EXCEPT in the label expression as well or
> > just properties?
> >
>
> I only implemented it for the properties because I couldn't find any
> example for Label expression using EXCEPT clause. So I thought it was
> only meant to be for the properties.
> But if you can confirm that we do use EXCEPT clauses with label
> expressions as well then I can try supporting that too.
>
> >
> > Please do not top-post on hackers.
> >
> > Always sent the whole patchset. Otherwise, CI bot gets confused. It
> > doesn't pick up patchset from the previous emails.
> >
> Okay, I will take care of that.
>
> > About the functionality: It's not clear to me whether an EXCEPT should
> > be applicable only at the time of property graph creation or it should
> > be applicable always. I.e. when a property graph is dumped, should it
> > have EXCEPT in it or have a list of columns surviving except list?
> > What if a column in except list is dropped after creating a property
> > graph?
> >
>
> I did some testing on that,  for now we are just dumping the columns
> surviving the except list.
> If an exceptional table column is deleted afterwards it doesn't show
> any effect on the graph. I also tested this scenario with duckdb pgq
> extension [1], deleting the col doesn't affect the graph.
>
> > Some comments on the code
>
> I am attaching a new patch after trying to fix according to you comments
>
> > 1. You could use list_member() in insert_property_records() to check
> > whether a given column is in the list of exceptions after you have
> > enveloped in String node.
>
> * I have changed to code to use list_member(), but I have to make
> ResTarget->name from `pstrdup(NameStr(att->attname));` to `NULL`
> We are using `xml_attribute_list` for our columns list and while
> making this list in gram.y we are assigning `rt->name` as NULL [2],
> this causes list_member() func to fail while comparing except_list
> nodes. That's why I am changing rt->name from string value to NULL in
> propgraphcmds.c in this patch.
>
> * Also, in order to use list_member() func I have to add a separate
> for loop to iterate through the exceptional columns to generate the
> error message if col is not valid. My question is, is it ok to use two
> separate for loops (one to check except cols validity &
> other(list_memeber) to check existence of scanned col in except list).
> In the previous patch I was using single for loop to validate both
> things.
>
> > 2. The SELECT with GRAPH_TABLE queries are tested in graph_table.sql.
> > We don't include those in create_property_graph.sql
>
> * I have moved the graph_table queries from create_property_graph.sql
> to graph_table.sql.
> * But in graph_table.sql I didn't use the existing graphs because
> those graphs and tables look like there for some specific test
> scenario, so I created my separate graph and table for my test
> scenario. I didn't drop the graph and the table as we will be dropping
> the schema at the end but Peter E has this comment "-- leave for
> pg_upgrade/pg_dump tests".
>
> > 3. Instead of creating a new property graph in the test, you may
> > modify one of the existing property graphs to have a label with except
> > list and then query it.
> >
>
> * I have modified the graphs in create_property_graph.sql in order to
> test except list cols in the alter command and create graph command.
>
> > We are aiming a minimal set of features in the first version. I will
> > let Peter E. decide whether to consider this as minimal set feature or
> > not. The feature looks useful to me.
>
> Thanks if you find this patch useful. I am attaching the modified patch.
>
> > 0001 - same as previous one
> > 0002 - fixes pgperltidy complaints
> > 0003 - fixes compilation failure
> > 0004 - fixes issue seen on CI
> > 0005 - adds support for WHERE clause in graph pattern missing in the
> > first patch.
> > 0006 - adds full support for cyclic path patterns
>
> 0007 - adds support for except cols list in graph properties
>
> Thanks
> Imran Zaheer
>
> [1]: https://github.com/cwida/duckpgq-extension
> [2]: https://github.com/postgres/postgres/blob/f5a1311fccd2ed24a9fb42aa47a17d1df7126039/src/backend/parser/gram.y#L16166

  17. Re: SQL Property Graph Queries (SQL/PGQ)

    Ajay Pal <ajay.pal.k@gmail.com> — 2024-08-13T10:38:07Z

    Hello,

Further testing found that using a property graph with the plpgsql
function crashed the server. Please take a look at the attached SQL
file for reference tables.

postgres=# create or replace function func() returns int as
postgres-# $$
postgres$# declare person_av varchar;
postgres$# begin
postgres$#
postgres$#         SELECT person_a into person_av FROM GRAPH_TABLE
(students_graph
postgres$#           MATCH
postgres$#           (a IS person) -[e IS friends]-> (b IS person
WHERE b.name = 'Bob')
postgres$#           WHERE a.name='John'
postgres$#           COLUMNS (a.name AS person_a, b.name AS person_b)
postgres$#         );
postgres$#
postgres$#         return person_av;
postgres$# end
postgres$# $$ language plpgsql;
CREATE FUNCTION
postgres=# select func();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
!?>

Please let me know if you need more details.

Thanks
Ajay

On Tue, Aug 13, 2024 at 3:22 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:
>
> Hello,
>
> With the attached patch found below error when try to use "Any
> directed edge" syntax.
>
> postgres=# SELECT * FROM GRAPH_TABLE (students_graph
> postgres(#   MATCH
> postgres(#   (a IS person )  - [] - (b IS person)
> postgres(#   COLUMNS (a.name AS person_a, b.name AS person_b)
> postgres(# );
> ERROR:  unsupported element pattern kind: undirected edge
>
> If this syntax is supported then should behave as below,
>
> PERSON_A   PERSON_B
> ---------- ----------
> Bob    John
> John    Mary
> Alice    Mary
> Mary    Bob
> Mary    John
> Bob    Mary
> John    Bob
> Mary    Alice
>
> 8 rows selected.
>
> Attaching the sql file for reference.
>
> Thanks
> Ajay
>
> On Sat, Aug 10, 2024 at 2:52 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> >
> > Hi Ashutosh,
> >
> > Thanks for the feedback.
> >
> > > Do you intend to support EXCEPT in the label expression as well or
> > > just properties?
> > >
> >
> > I only implemented it for the properties because I couldn't find any
> > example for Label expression using EXCEPT clause. So I thought it was
> > only meant to be for the properties.
> > But if you can confirm that we do use EXCEPT clauses with label
> > expressions as well then I can try supporting that too.
> >
> > >
> > > Please do not top-post on hackers.
> > >
> > > Always sent the whole patchset. Otherwise, CI bot gets confused. It
> > > doesn't pick up patchset from the previous emails.
> > >
> > Okay, I will take care of that.
> >
> > > About the functionality: It's not clear to me whether an EXCEPT should
> > > be applicable only at the time of property graph creation or it should
> > > be applicable always. I.e. when a property graph is dumped, should it
> > > have EXCEPT in it or have a list of columns surviving except list?
> > > What if a column in except list is dropped after creating a property
> > > graph?
> > >
> >
> > I did some testing on that,  for now we are just dumping the columns
> > surviving the except list.
> > If an exceptional table column is deleted afterwards it doesn't show
> > any effect on the graph. I also tested this scenario with duckdb pgq
> > extension [1], deleting the col doesn't affect the graph.
> >
> > > Some comments on the code
> >
> > I am attaching a new patch after trying to fix according to you comments
> >
> > > 1. You could use list_member() in insert_property_records() to check
> > > whether a given column is in the list of exceptions after you have
> > > enveloped in String node.
> >
> > * I have changed to code to use list_member(), but I have to make
> > ResTarget->name from `pstrdup(NameStr(att->attname));` to `NULL`
> > We are using `xml_attribute_list` for our columns list and while
> > making this list in gram.y we are assigning `rt->name` as NULL [2],
> > this causes list_member() func to fail while comparing except_list
> > nodes. That's why I am changing rt->name from string value to NULL in
> > propgraphcmds.c in this patch.
> >
> > * Also, in order to use list_member() func I have to add a separate
> > for loop to iterate through the exceptional columns to generate the
> > error message if col is not valid. My question is, is it ok to use two
> > separate for loops (one to check except cols validity &
> > other(list_memeber) to check existence of scanned col in except list).
> > In the previous patch I was using single for loop to validate both
> > things.
> >
> > > 2. The SELECT with GRAPH_TABLE queries are tested in graph_table.sql.
> > > We don't include those in create_property_graph.sql
> >
> > * I have moved the graph_table queries from create_property_graph.sql
> > to graph_table.sql.
> > * But in graph_table.sql I didn't use the existing graphs because
> > those graphs and tables look like there for some specific test
> > scenario, so I created my separate graph and table for my test
> > scenario. I didn't drop the graph and the table as we will be dropping
> > the schema at the end but Peter E has this comment "-- leave for
> > pg_upgrade/pg_dump tests".
> >
> > > 3. Instead of creating a new property graph in the test, you may
> > > modify one of the existing property graphs to have a label with except
> > > list and then query it.
> > >
> >
> > * I have modified the graphs in create_property_graph.sql in order to
> > test except list cols in the alter command and create graph command.
> >
> > > We are aiming a minimal set of features in the first version. I will
> > > let Peter E. decide whether to consider this as minimal set feature or
> > > not. The feature looks useful to me.
> >
> > Thanks if you find this patch useful. I am attaching the modified patch.
> >
> > > 0001 - same as previous one
> > > 0002 - fixes pgperltidy complaints
> > > 0003 - fixes compilation failure
> > > 0004 - fixes issue seen on CI
> > > 0005 - adds support for WHERE clause in graph pattern missing in the
> > > first patch.
> > > 0006 - adds full support for cyclic path patterns
> >
> > 0007 - adds support for except cols list in graph properties
> >
> > Thanks
> > Imran Zaheer
> >
> > [1]: https://github.com/cwida/duckpgq-extension
> > [2]: https://github.com/postgres/postgres/blob/f5a1311fccd2ed24a9fb42aa47a17d1df7126039/src/backend/parser/gram.y#L16166

  18. Re: SQL Property Graph Queries (SQL/PGQ)

    Ajay Pal <ajay.pal.k@gmail.com> — 2024-08-20T11:50:41Z

    Hi All,

When we use a graph table and any local table, the server crashes.
Please note, It is happening when using the where clause for the local
table only.

postgres=# SELECT * FROM customers a, GRAPH_TABLE (myshop2 MATCH (c IS
customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders)
COLUMNS (c.name_redacted AS customer_name_redacted));
 customer_id |   name    | address | customer_name_redacted
-------------+-----------+---------+------------------------
           1 | customer1 | US      | redacted1
           2 | customer2 | CA      | redacted1
           3 | customer3 | GL      | redacted1
(3 rows)

postgres=# SELECT * FROM customers a, GRAPH_TABLE (myshop2 MATCH (c IS
customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders)
COLUMNS (c.name_redacted AS customer_name_redacted)) where
a.customer_id=1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
!?> \q

Note:- I have referred to graph_table.sql to get the table structure
used in the above query.

Thanks
Ajay


On Tue, Aug 13, 2024 at 4:08 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:
>
> Hello,
>
> Further testing found that using a property graph with the plpgsql
> function crashed the server. Please take a look at the attached SQL
> file for reference tables.
>
> postgres=# create or replace function func() returns int as
> postgres-# $$
> postgres$# declare person_av varchar;
> postgres$# begin
> postgres$#
> postgres$#         SELECT person_a into person_av FROM GRAPH_TABLE
> (students_graph
> postgres$#           MATCH
> postgres$#           (a IS person) -[e IS friends]-> (b IS person
> WHERE b.name = 'Bob')
> postgres$#           WHERE a.name='John'
> postgres$#           COLUMNS (a.name AS person_a, b.name AS person_b)
> postgres$#         );
> postgres$#
> postgres$#         return person_av;
> postgres$# end
> postgres$# $$ language plpgsql;
> CREATE FUNCTION
> postgres=# select func();
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
> !?>
>
> Please let me know if you need more details.
>
> Thanks
> Ajay
>
> On Tue, Aug 13, 2024 at 3:22 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:
> >
> > Hello,
> >
> > With the attached patch found below error when try to use "Any
> > directed edge" syntax.
> >
> > postgres=# SELECT * FROM GRAPH_TABLE (students_graph
> > postgres(#   MATCH
> > postgres(#   (a IS person )  - [] - (b IS person)
> > postgres(#   COLUMNS (a.name AS person_a, b.name AS person_b)
> > postgres(# );
> > ERROR:  unsupported element pattern kind: undirected edge
> >
> > If this syntax is supported then should behave as below,
> >
> > PERSON_A   PERSON_B
> > ---------- ----------
> > Bob    John
> > John    Mary
> > Alice    Mary
> > Mary    Bob
> > Mary    John
> > Bob    Mary
> > John    Bob
> > Mary    Alice
> >
> > 8 rows selected.
> >
> > Attaching the sql file for reference.
> >
> > Thanks
> > Ajay
> >
> > On Sat, Aug 10, 2024 at 2:52 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > Thanks for the feedback.
> > >
> > > > Do you intend to support EXCEPT in the label expression as well or
> > > > just properties?
> > > >
> > >
> > > I only implemented it for the properties because I couldn't find any
> > > example for Label expression using EXCEPT clause. So I thought it was
> > > only meant to be for the properties.
> > > But if you can confirm that we do use EXCEPT clauses with label
> > > expressions as well then I can try supporting that too.
> > >
> > > >
> > > > Please do not top-post on hackers.
> > > >
> > > > Always sent the whole patchset. Otherwise, CI bot gets confused. It
> > > > doesn't pick up patchset from the previous emails.
> > > >
> > > Okay, I will take care of that.
> > >
> > > > About the functionality: It's not clear to me whether an EXCEPT should
> > > > be applicable only at the time of property graph creation or it should
> > > > be applicable always. I.e. when a property graph is dumped, should it
> > > > have EXCEPT in it or have a list of columns surviving except list?
> > > > What if a column in except list is dropped after creating a property
> > > > graph?
> > > >
> > >
> > > I did some testing on that,  for now we are just dumping the columns
> > > surviving the except list.
> > > If an exceptional table column is deleted afterwards it doesn't show
> > > any effect on the graph. I also tested this scenario with duckdb pgq
> > > extension [1], deleting the col doesn't affect the graph.
> > >
> > > > Some comments on the code
> > >
> > > I am attaching a new patch after trying to fix according to you comments
> > >
> > > > 1. You could use list_member() in insert_property_records() to check
> > > > whether a given column is in the list of exceptions after you have
> > > > enveloped in String node.
> > >
> > > * I have changed to code to use list_member(), but I have to make
> > > ResTarget->name from `pstrdup(NameStr(att->attname));` to `NULL`
> > > We are using `xml_attribute_list` for our columns list and while
> > > making this list in gram.y we are assigning `rt->name` as NULL [2],
> > > this causes list_member() func to fail while comparing except_list
> > > nodes. That's why I am changing rt->name from string value to NULL in
> > > propgraphcmds.c in this patch.
> > >
> > > * Also, in order to use list_member() func I have to add a separate
> > > for loop to iterate through the exceptional columns to generate the
> > > error message if col is not valid. My question is, is it ok to use two
> > > separate for loops (one to check except cols validity &
> > > other(list_memeber) to check existence of scanned col in except list).
> > > In the previous patch I was using single for loop to validate both
> > > things.
> > >
> > > > 2. The SELECT with GRAPH_TABLE queries are tested in graph_table.sql.
> > > > We don't include those in create_property_graph.sql
> > >
> > > * I have moved the graph_table queries from create_property_graph.sql
> > > to graph_table.sql.
> > > * But in graph_table.sql I didn't use the existing graphs because
> > > those graphs and tables look like there for some specific test
> > > scenario, so I created my separate graph and table for my test
> > > scenario. I didn't drop the graph and the table as we will be dropping
> > > the schema at the end but Peter E has this comment "-- leave for
> > > pg_upgrade/pg_dump tests".
> > >
> > > > 3. Instead of creating a new property graph in the test, you may
> > > > modify one of the existing property graphs to have a label with except
> > > > list and then query it.
> > > >
> > >
> > > * I have modified the graphs in create_property_graph.sql in order to
> > > test except list cols in the alter command and create graph command.
> > >
> > > > We are aiming a minimal set of features in the first version. I will
> > > > let Peter E. decide whether to consider this as minimal set feature or
> > > > not. The feature looks useful to me.
> > >
> > > Thanks if you find this patch useful. I am attaching the modified patch.
> > >
> > > > 0001 - same as previous one
> > > > 0002 - fixes pgperltidy complaints
> > > > 0003 - fixes compilation failure
> > > > 0004 - fixes issue seen on CI
> > > > 0005 - adds support for WHERE clause in graph pattern missing in the
> > > > first patch.
> > > > 0006 - adds full support for cyclic path patterns
> > >
> > > 0007 - adds support for except cols list in graph properties
> > >
> > > Thanks
> > > Imran Zaheer
> > >
> > > [1]: https://github.com/cwida/duckpgq-extension
> > > [2]: https://github.com/postgres/postgres/blob/f5a1311fccd2ed24a9fb42aa47a17d1df7126039/src/backend/parser/gram.y#L16166

  19. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-08-28T10:18:46Z

    On Tue, Aug 13, 2024 at 3:22 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:

>
> With the attached patch found below error when try to use "Any
> directed edge" syntax.
>
> postgres=# SELECT * FROM GRAPH_TABLE (students_graph
> postgres(#   MATCH
> postgres(#   (a IS person )  - [] - (b IS person)
> postgres(#   COLUMNS (a.name AS person_a, b.name AS person_b)
> postgres(# );
> ERROR:  unsupported element pattern kind: undirected edge
>

Earlier patches treated syntax "-[]- " as undirected edge and didn't
support it. Per standard it is specifies an edge in either direction
which is equivalent of -[]-> OR <-[]-. Implemented in the attached
patches. Also added a test case in graph_table.sql.

On Tue, Aug 13, 2024 at 4:08 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:

> postgres=# create or replace function func() returns int as
> postgres-# $$
> postgres$# declare person_av varchar;
> postgres$# begin
> postgres$#
> postgres$#         SELECT person_a into person_av FROM GRAPH_TABLE
> (students_graph
> postgres$#           MATCH
> postgres$#           (a IS person) -[e IS friends]-> (b IS person
> WHERE b.name = 'Bob')
> postgres$#           WHERE a.name='John'
> postgres$#           COLUMNS (a.name AS person_a, b.name AS person_b)
> postgres$#         );
> postgres$#
> postgres$#         return person_av;
> postgres$# end
> postgres$# $$ language plpgsql;
> CREATE FUNCTION
> postgres=# select func();
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
> !?>
>

Nice catch. The crash happens because earlier patches implemented
parser hooks to resolve graph property references. Those
implementations conflicted with the same hooks implemented in plpgsql
code. The attached patches fix this by adding a member to ParseState
instead of using hooks. Once this was fixed, there was another
problem. Property graph referenced in GRAPH_TABLE was not being
locked. That problem is fixed in the attached patches as well.

On Tue, Aug 20, 2024 at 5:20 PM Ajay Pal <ajay.pal.k@gmail.com> wrote:
>
> Hi All,
>
> When we use a graph table and any local table, the server crashes.
> Please note, It is happening when using the where clause for the local
> table only.
>
> postgres=# SELECT * FROM customers a, GRAPH_TABLE (myshop2 MATCH (c IS
> customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders)
> COLUMNS (c.name_redacted AS customer_name_redacted));
>  customer_id |   name    | address | customer_name_redacted
> -------------+-----------+---------+------------------------
>            1 | customer1 | US      | redacted1
>            2 | customer2 | CA      | redacted1
>            3 | customer3 | GL      | redacted1
> (3 rows)
>
> postgres=# SELECT * FROM customers a, GRAPH_TABLE (myshop2 MATCH (c IS
> customers WHERE c.address = 'US')-[IS customer_orders]->(o IS orders)
> COLUMNS (c.name_redacted AS customer_name_redacted)) where
> a.customer_id=1;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
> !?> \q
>

This problem is not reproducible after fixing other problem. Please
let me know if it's reproduces for you. If it reproduces please
provide a patch adding the reproduction to graph_table.sql.

Along with this I have rebased the patches on the latest HEAD, fixed
some comments, code styles etc.

Patches 0001 - 0006 are same as the previous set.
0007 - fixes all the problems you reported till now and also the one I
found. The commit message describes the fixes in detail.

-- 
Best Wishes,
Ashutosh Bapat

  20. Re: SQL Property Graph Queries (SQL/PGQ)

    Andreas Karlsson <andreas@proxel.se> — 2024-10-29T19:55:25Z

    > Patches 0001 - 0006 are same as the previous set.
> 0007 - fixes all the problems you reported till now and also the one I
> found. The commit message describes the fixes in detail.

Hi,

I found a potential bug in the parsing of the left and right arrows. 
They can be broken up in - > and < - respectively. Does the SQL/PGQ 
standard really allow this?

I found this while working on a patch of our own and I was trying to 
figure out how you guys had solved this very same problem that we ran 
into, and if you had done so in a better way. The fundamental problem is 
that parsing the left arrow as one token is a bit tricky due to how 
PostgreSQL treats operators ending with minus or plus.

I have attached our very ugly solution for it (broken out from our 
patch) in case it helps you. Feel free to use it or ignore it. We do not 
plan to work on this right now since you are already working on the same 
problem.

I especially dislike the static variable in our patch. And as far as I 
understand it you can avoid the static by changing the lexer to use the 
push parser so it can emit multiple terminal tokens from one parsed 
token, but I have not looked into push parsers and have no idea how this 
would affect performance.

https://www.gnu.org/software/bison/manual/html_node/Push-Decl.html

Examples:

# SELECT count(*) FROM GRAPH_TABLE (g1 MATCH ()-[]->() COLUMNS (1 as one));
  count
-------
     32
(1 row)

# SELECT count(*) FROM GRAPH_TABLE (g1 MATCH ()-[]- >() COLUMNS (1 as one));
  count
-------
     32
(1 row)

# SELECT * FROM GRAPH_TABLE (myshop MATCH (o IS orders)<-[IS 
customer_orders]-(c IS customers) COLUMNS (c.name, o.ordered_when));
    name    | ordered_when
-----------+--------------
  customer1 | 2024-01-01
  customer2 | 2024-01-02
(2 rows)

# SELECT * FROM GRAPH_TABLE (myshop MATCH (o IS orders)< -[IS 
customer_orders]-(c IS customers) COLUMNS (c.name, o.ordered_when));
    name    | ordered_when
-----------+--------------
  customer1 | 2024-01-01
  customer2 | 2024-01-02
(2 rows)

Andreas

  21. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-11-05T15:41:24Z

    On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Patches 0001 - 0006 are same as the previous set.
> 0007 - fixes all the problems you reported till now and also the one I
> found. The commit message describes the fixes in detail.

Here's an updated patchset based on the latest HEAD.

0001
So far I was keeping the 0001 patch the same as the one Peter posted
at [1]. But it has accumulated few conflicts and compilation failures
over the months. Thus that patch by itself is not of much use. In this
patch set 0001 is that patch + fixes for conflicts, compilation
failures and perltidy adjustments accumulated over the months. This
allows that patch to be applied and tested independently. Commit
message describes the fixes.

0002 -  adds support for WHERE clause in graph pattern

0003 - adds full support for cyclic path patterns

0004 - fixes all the bugs reported by Ajay and also the one found by
me. Commit message describes all the issues

0005
Tests privileges with GRAPH_TABLE. Table level privileges are being
honoured by previous patches by creating approprate RTEPermissionInfos
for the underlying tables when rewriting GRAPH_TABLE entry. But those
patches do not honour column privileges. This patch adds the columns
used in the GRAPH_TABLE to RTEPermissionInfos::selectedCols to honour
column level privileges. Below are the access rules for property graph
and the tables underlying GRAPH_TABLE entry.

1. A user needs SELECT privilege to access a property graph in the query.
2. The property graph itself acts similar to a security invoker view
in the sense that the current_user should have privileges to access
the tables and columns, underlying the graph pattern. For example, a
property graph g1 contains graph element tables e1 and e2. Assume two
users u1 and u2 with privileges to access e1 and e2 respectively.
Let's also assume that they have privileges to access the property
graph g1. u1, as the current user, would be able to run query
involving g1 successfully as long as it does *not* require access to
e2.  Similarly u2 would be able to run a query involving g1
successfully as long as it does *not* require access to e1.
3. If a property graph is referenced in a security definer view,
access to the property graph is governed by the privileges of the
owner of the view but the access to the base relations underlying the
graph pattern are governed by the privileges of the user executing the
query. This is similar to how access to the base relations underlying
a security invoker view referenced from a security definer view is
handled. access
4. We have not implemented security definer property graphs since
SQL/PGQ standard does not mention those.

Per SQL/PGQ standard, a property graph can contain any relation as
long as it has SELECT privilege on that relation ("Access rules"
subsection of section 11.19 <property graph definition>". Current
implementation of property graph DDL does not allow a table owned by a
user other than the owner property graph to be added to the property
graph. I haven't changed that in this patch. But in case we implement
what the standard suggests, it will become much easier to add queries
to test privileges and access vs property graph containing views. So I
have left those test aside for now.

0006 - is a temporary fix to provide collation to the operator joining
edges to their adjacent tables. It is required for some tests added in
0007.

0007
Adds queries to test RLS against GRAPH_TABLE. rowsecurity.sql has an
extensive set of tests for RLS. The commits add new queries equivalent
to existing ones but using GRAPH_TABLE construct. The tests covering
simple tables, inheritance and partitioned tables establish that the
RLS is applied even when the tables are accessed through GRAPH_TABLE.
That is good enough to assume that the RLS policies will be applied
and handled correctly when interacting with other features like
prepared statement invalidation, security barrier views, CTE, INSERT
... SELECT, COPY, joins, non-target relations etc. This assumption is
based on the current implementation which rewrites GRAPH_TABLE RTE
well before the RLS policies are added. In case the implementation
changes in future, these extensive set of new queries will provide the
extensive coverage. We might decide to reduce the number of new
queries later. But for now, I have kept all those queries in this
patch. Hence a separate patch.

Work in 0005 and 0006 together is intended to make sure a bad actor
doesn't exploit property graphs to access data which is not available
to them otherwise.

Next I will work on finishing 0006 and implement the complete code to
construct quals joining edges to their adjacent tables.

[1] https://www.postgresql.org/message-id/a855795d-e697-4fa5-8698-d20122126567%40eisentraut.org

--
Best Wishes,
Ashutosh Bapat

  22. Re: SQL Property Graph Queries (SQL/PGQ)

    Vik Fearing <vik@postgresfriends.org> — 2024-11-19T16:38:36Z

    On 05/11/2024 16:41, Ashutosh Bapat wrote:
> On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>> Patches 0001 - 0006 are same as the previous set.
>> 0007 - fixes all the problems you reported till now and also the one I
>> found. The commit message describes the fixes in detail.
> Here's an updated patchset based on the latest HEAD.



I have been looking at this patchset from a user's and standards' 
perspective and I am quite pleased with what I am seeing for the most 
part.  I have not been looking much at the code itself, although I do 
plan on reviewing some of the code in the future.


There are a few things that stick out to me.


1.
I don't see any way to view the structure of of a property graph.  For 
example:


postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape 
VARCHAR, size INTEGER);
CREATE TABLE
postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY 
(id) PROPERTIES ALL COLUMNS);
CREATE PROPERTY GRAPH
postgres=# \dG propgraph
                       List of relations
       Schema       |   Name    | Type      |    Owner
-------------------+-----------+----------------+-------------
  graph_table_tests | propgraph | property graph | vik.fearing
(1 row)

postgres=# \d propgraph
Property graph "graph_table_tests.propgraph"
  Column | Type
--------+------

I don't really know what to do with that.


2.
There is a missing newline in the \? help of psql.
     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
     HELP0("  \\dl[+]                 list large objects, same as 
\\lo_list\n");



3.
The noise word "ARE" is missing from the <element table properties 
alternatives>clause.
There is also no support for the EXCEPT clause, but I imagine that can 
be added at a later time.


4.
I notice that tables in pg_catalog are not allowed in a property graph.  
What are the reasons for this?  It is true that this might cause some 
problems with upgrades if a column is removed, but it shouldn't cause 
trouble for columns being added.  That case works with user tables.

5.

The ascii art characters (I am loathe to call them operators) allow junk 
in between them.  For example:


     MATCH (c) -[:lbl]-> (d)

can be written as


     MATCH (c) -
         [:lbl] -
         /* a comment here */
         > (d)


Is that intentional?


----


I will continue to review this feature from the user's perspective.  
Thank you for working on it, I am very excited to get this in.

-- 

Vik Fearing

  23. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-11-22T13:59:16Z

    On Tue, Nov 19, 2024 at 10:08 PM Vik Fearing <vik@postgresfriends.org> wrote:
>
>
> On 05/11/2024 16:41, Ashutosh Bapat wrote:
>
> On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>
> Patches 0001 - 0006 are same as the previous set.
> 0007 - fixes all the problems you reported till now and also the one I
> found. The commit message describes the fixes in detail.
>
> Here's an updated patchset based on the latest HEAD.
>
>
>
> I have been looking at this patchset from a user's and standards' perspective and I am quite pleased with what I am seeing for the most part.  I have not been looking much at the code itself, although I do plan on reviewing some of the code in the future.

Thanks for looking at the patches.

>
>
> There are a few things that stick out to me.
>
>
> 1.
> I don't see any way to view the structure of of a property graph.  For example:
>
>
> postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape VARCHAR, size INTEGER);
> CREATE TABLE
> postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY (id) PROPERTIES ALL COLUMNS);
> CREATE PROPERTY GRAPH
> postgres=# \dG propgraph
>                       List of relations
>       Schema       |   Name    |      Type      |    Owner
> -------------------+-----------+----------------+-------------
>  graph_table_tests | propgraph | property graph | vik.fearing
> (1 row)
>
> postgres=# \d propgraph
> Property graph "graph_table_tests.propgraph"
>  Column | Type
> --------+------
>
> I don't really know what to do with that.

Yes. It is on my TODO list. IMO we should just print the first line
property graph "...". There are no predefined columns in this
relation. And somehow redirect them to use \dG instead.
>
>
> 2.
> There is a missing newline in the \? help of psql.
>     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
>     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
>     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
>     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
>     HELP0("  \\dl[+]                 list large objects, same as \\lo_list\n");
>

Will fix that in the next set. I notice that \dGS+ doesn't provide a
lot of information.
\dG+
                                 List of relations
 Schema | Name |      Type      |   Owner    | Persistence |  Size   |
Description
--------+------+----------------+------------+-------------+---------+-------------
 public | g1   | property graph | ashutoshpg | permanent   | 0 bytes |
(1 row)

Maybe it should print elements, their labels and properties.

>
>
> 3.
> The noise word "ARE" is missing from the <element table properties alternatives> clause.

Agreed. Possibly in v2 since it doesn't affect the functionality.

> There is also no support for the EXCEPT clause, but I imagine that can be added at a later time.
>

There's a patch proposed at [1], but there are some things missing
there. I guess it will be added at a later time.

>
> 4.
> I notice that tables in pg_catalog are not allowed in a property graph.  What are the reasons for this?  It is true that this might cause some problems with upgrades if a column is removed, but it shouldn't cause trouble for columns being added.  That case works with user tables.
>

I don't know the reason. We don't allow tables belonging to other
users to be part of the property graph as explained in [3]. Those two
might have the same context. Maybe Peter can explain.

> 5.
>
> The ascii art characters (I am loathe to call them operators) allow junk in between them.  For example:
>
>
>     MATCH (c) -[:lbl]-> (d)
>
> can be written as
>
>
>     MATCH (c) -
>         [:lbl] -
>         /* a comment here */
>         > (d)
>
>
> Is that intentional?

This looks similar to [2]. I think it has to do with the way we parse
operators. But I haven't investigated it.

>
> I will continue to review this feature from the user's perspective.  Thank you for working on it, I am very excited to get this in.

Thanks again.

Here's the latest version of patches rebased on
aac831cafa6f3106dfcbd3298757801c299351fc. I have fixed merge
conflicts, compilation issues and also fixed the failure seen on CI
from the previous patch set.

0001 - 0005 are the same as the previous set.
0007 - has RLS tests. It is the same as 0006 from the previous patch set.

0006 - is new addressing collation and edge-vertex link qual creation.
This patch adds code to store collation and typmod to
pg_propgraph_property catalog and propagate it to property graph
references in GRAPH_TABLE. Collation is used by
assign_query_collations and assign_expr_collations to propagate
collation up the query and expression tree respectively. typmod is
used to report typmod of property reference from exprTypemod().

While finishing code to create vertex-edge link quals, I found that we
need to find and store the operator to be used for key matching in
those quals. I think we have to do something similar to what primary
key handling code does - find the equality operator when creating edge
descriptor and store it in pg_propgraph_element. I am not sure whether
we should add a dependency on the operator. I will look into this
next.


[1] https://www.postgresql.org/message-id/CA+UBfakRHrTqTkx8W0cmxGD7zfnZkZ4nczUvp0FGF68LvMSG-A@mail.gmail.com
[2] https://www.postgresql.org/message-id/0b862b93-dc70-4ba1-b27f-e09104bc4c2c@proxel.se
[3] https://www.postgresql.org/message-id/CAExHW5serNyfY4v9oy6us=tM7ZyAd3_gYnMjOmRPk8eWEskSog@mail.gmail.com

-- 
Best Wishes,
Ashutosh Bapat

  24. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-12-05T11:08:35Z

    On Fri, Nov 22, 2024 at 7:29 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Nov 19, 2024 at 10:08 PM Vik Fearing <vik@postgresfriends.org> wrote:
> >
> >
> > On 05/11/2024 16:41, Ashutosh Bapat wrote:
> >
> > On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > Patches 0001 - 0006 are same as the previous set.
> > 0007 - fixes all the problems you reported till now and also the one I
> > found. The commit message describes the fixes in detail.
> >
> > Here's an updated patchset based on the latest HEAD.
> >
> >
> >
> > I have been looking at this patchset from a user's and standards' perspective and I am quite pleased with what I am seeing for the most part.  I have not been looking much at the code itself, although I do plan on reviewing some of the code in the future.
>
> Thanks for looking at the patches.
>
> >
> >
> > There are a few things that stick out to me.
> >
> >
> > 1.
> > I don't see any way to view the structure of of a property graph.  For example:
> >
> >
> > postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape VARCHAR, size INTEGER);
> > CREATE TABLE
> > postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY (id) PROPERTIES ALL COLUMNS);
> > CREATE PROPERTY GRAPH
> > postgres=# \dG propgraph
> >                       List of relations
> >       Schema       |   Name    |      Type      |    Owner
> > -------------------+-----------+----------------+-------------
> >  graph_table_tests | propgraph | property graph | vik.fearing
> > (1 row)
> >
> > postgres=# \d propgraph
> > Property graph "graph_table_tests.propgraph"
> >  Column | Type
> > --------+------
> >
> > I don't really know what to do with that.
>
> Yes. It is on my TODO list. IMO we should just print the first line
> property graph "...". There are no predefined columns in this
> relation. And somehow redirect them to use \dG instead.

\d+ propgraph prints the definition of property graph. I find \dG
similar to \di which doesn't print the structure of an index. Instead
\d+ <index name> prints it.

In the attached patch series I have added patch 0008 to remove
unnecessary header
> >  Column | Type
> > --------+------

It still prints an extra line but I haven't found a way to eliminate
it. Hence 0008 is WIP. I have listed TODOs in the commit message of
that patch.


> >
> >
> > 2.
> > There is a missing newline in the \? help of psql.
> >     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
> >     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
> >     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
> >     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
> >     HELP0("  \\dl[+]                 list large objects, same as \\lo_list\n");
> >
>
> Will fix that in the next set.

Done. The fix is part of 0001 now.



>
> >
> > I will continue to review this feature from the user's perspective.  Thank you for working on it, I am very excited to get this in.
>

here's patchset rebased on 792b2c7e6d926e61e8ff3b33d3e22d7d74e7a437
with conflicts in rowsecurity.sql/out fixed.

>
> 0001 - 0005 are the same as the previous set.
> 0007 - has RLS tests. It is the same as 0006 from the previous patch set.

This is same as the previous patchset.

>
> 0006 - is new addressing collation and edge-vertex link qual creation.
> This patch adds code to store collation and typmod to
> pg_propgraph_property catalog and propagate it to property graph
> references in GRAPH_TABLE. Collation is used by
> assign_query_collations and assign_expr_collations to propagate
> collation up the query and expression tree respectively. typmod is
> used to report typmod of property reference from exprTypemod().
>
> While finishing code to create vertex-edge link quals, I found that we
> need to find and store the operator to be used for key matching in
> those quals. I think we have to do something similar to what primary
> key handling code does - find the equality operator when creating edge
> descriptor and store it in pg_propgraph_element. I am not sure whether
> we should add a dependency on the operator. I will look into this
> next.

0006 in the attached patch series completes this work. Now we find the
equality operators to be used for vertex-edge quals and save it in
pg_propgraph_element catalog and also add a dependency between the
edge element and the equality operators.

0008 - has WIP fix for \d and \d+

--
Best Wishes,
Ashutosh Bapat

  25. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-12-05T11:42:11Z

    Sorry, I forgot to attach patches. PFA the patches.

On Thu, Dec 5, 2024 at 4:38 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Fri, Nov 22, 2024 at 7:29 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Tue, Nov 19, 2024 at 10:08 PM Vik Fearing <vik@postgresfriends.org> wrote:
> > >
> > >
> > > On 05/11/2024 16:41, Ashutosh Bapat wrote:
> > >
> > > On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> > > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > Patches 0001 - 0006 are same as the previous set.
> > > 0007 - fixes all the problems you reported till now and also the one I
> > > found. The commit message describes the fixes in detail.
> > >
> > > Here's an updated patchset based on the latest HEAD.
> > >
> > >
> > >
> > > I have been looking at this patchset from a user's and standards' perspective and I am quite pleased with what I am seeing for the most part.  I have not been looking much at the code itself, although I do plan on reviewing some of the code in the future.
> >
> > Thanks for looking at the patches.
> >
> > >
> > >
> > > There are a few things that stick out to me.
> > >
> > >
> > > 1.
> > > I don't see any way to view the structure of of a property graph.  For example:
> > >
> > >
> > > postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape VARCHAR, size INTEGER);
> > > CREATE TABLE
> > > postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY (id) PROPERTIES ALL COLUMNS);
> > > CREATE PROPERTY GRAPH
> > > postgres=# \dG propgraph
> > >                       List of relations
> > >       Schema       |   Name    |      Type      |    Owner
> > > -------------------+-----------+----------------+-------------
> > >  graph_table_tests | propgraph | property graph | vik.fearing
> > > (1 row)
> > >
> > > postgres=# \d propgraph
> > > Property graph "graph_table_tests.propgraph"
> > >  Column | Type
> > > --------+------
> > >
> > > I don't really know what to do with that.
> >
> > Yes. It is on my TODO list. IMO we should just print the first line
> > property graph "...". There are no predefined columns in this
> > relation. And somehow redirect them to use \dG instead.
>
> \d+ propgraph prints the definition of property graph. I find \dG
> similar to \di which doesn't print the structure of an index. Instead
> \d+ <index name> prints it.
>
> In the attached patch series I have added patch 0008 to remove
> unnecessary header
> > >  Column | Type
> > > --------+------
>
> It still prints an extra line but I haven't found a way to eliminate
> it. Hence 0008 is WIP. I have listed TODOs in the commit message of
> that patch.
>
>
> > >
> > >
> > > 2.
> > > There is a missing newline in the \? help of psql.
> > >     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
> > >     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
> > >     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
> > >     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
> > >     HELP0("  \\dl[+]                 list large objects, same as \\lo_list\n");
> > >
> >
> > Will fix that in the next set.
>
> Done. The fix is part of 0001 now.
>
>
>
> >
> > >
> > > I will continue to review this feature from the user's perspective.  Thank you for working on it, I am very excited to get this in.
> >
>
> here's patchset rebased on 792b2c7e6d926e61e8ff3b33d3e22d7d74e7a437
> with conflicts in rowsecurity.sql/out fixed.
>
> >
> > 0001 - 0005 are the same as the previous set.
> > 0007 - has RLS tests. It is the same as 0006 from the previous patch set.
>
> This is same as the previous patchset.
>
> >
> > 0006 - is new addressing collation and edge-vertex link qual creation.
> > This patch adds code to store collation and typmod to
> > pg_propgraph_property catalog and propagate it to property graph
> > references in GRAPH_TABLE. Collation is used by
> > assign_query_collations and assign_expr_collations to propagate
> > collation up the query and expression tree respectively. typmod is
> > used to report typmod of property reference from exprTypemod().
> >
> > While finishing code to create vertex-edge link quals, I found that we
> > need to find and store the operator to be used for key matching in
> > those quals. I think we have to do something similar to what primary
> > key handling code does - find the equality operator when creating edge
> > descriptor and store it in pg_propgraph_element. I am not sure whether
> > we should add a dependency on the operator. I will look into this
> > next.
>
> 0006 in the attached patch series completes this work. Now we find the
> equality operators to be used for vertex-edge quals and save it in
> pg_propgraph_element catalog and also add a dependency between the
> edge element and the equality operators.
>
> 0008 - has WIP fix for \d and \d+
>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Best Wishes,
Ashutosh Bapat

  26. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2024-12-14T13:53:05Z

    Hi Ashutosh,

On Fri, Dec 6, 2024 at 12:34 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Sorry, I forgot to attach patches. PFA the patches.
>
> On Thu, Dec 5, 2024 at 4:38 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Fri, Nov 22, 2024 at 7:29 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Tue, Nov 19, 2024 at 10:08 PM Vik Fearing <vik@postgresfriends.org> wrote:
> > > >
> > > >
> > > > On 05/11/2024 16:41, Ashutosh Bapat wrote:
> > > >
> > > > On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> > > > <ashutosh.bapat.oss@gmail.com> wrote:
> > > >
> > > > Patches 0001 - 0006 are same as the previous set.
> > > > 0007 - fixes all the problems you reported till now and also the one I
> > > > found. The commit message describes the fixes in detail.
> > > >
> > > > Here's an updated patchset based on the latest HEAD.
> > > >
> > > >
> > > >
> > > > I have been looking at this patchset from a user's and standards' perspective and I am quite pleased with what I am seeing for the most part.  I have not been looking much at the code itself, although I do plan on reviewing some of the code in the future.
> > >
> > > Thanks for looking at the patches.
> > >
> > > >
> > > >
> > > > There are a few things that stick out to me.
> > > >
> > > >
> > > > 1.
> > > > I don't see any way to view the structure of of a property graph.  For example:
> > > >
> > > >
> > > > postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape VARCHAR, size INTEGER);
> > > > CREATE TABLE
> > > > postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY (id) PROPERTIES ALL COLUMNS);
> > > > CREATE PROPERTY GRAPH
> > > > postgres=# \dG propgraph
> > > >                       List of relations
> > > >       Schema       |   Name    |      Type      |    Owner
> > > > -------------------+-----------+----------------+-------------
> > > >  graph_table_tests | propgraph | property graph | vik.fearing
> > > > (1 row)
> > > >
> > > > postgres=# \d propgraph
> > > > Property graph "graph_table_tests.propgraph"
> > > >  Column | Type
> > > > --------+------
> > > >
> > > > I don't really know what to do with that.
> > >
> > > Yes. It is on my TODO list. IMO we should just print the first line
> > > property graph "...". There are no predefined columns in this
> > > relation. And somehow redirect them to use \dG instead.
> >
> > \d+ propgraph prints the definition of property graph. I find \dG
> > similar to \di which doesn't print the structure of an index. Instead
> > \d+ <index name> prints it.
> >
> > In the attached patch series I have added patch 0008 to remove
> > unnecessary header
> > > >  Column | Type
> > > > --------+------
> >
> > It still prints an extra line but I haven't found a way to eliminate
> > it. Hence 0008 is WIP. I have listed TODOs in the commit message of
> > that patch.
> >
> >
> > > >
> > > >
> > > > 2.
> > > > There is a missing newline in the \? help of psql.
> > > >     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
> > > >     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
> > > >     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
> > > >     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
> > > >     HELP0("  \\dl[+]                 list large objects, same as \\lo_list\n");
> > > >
> > >
> > > Will fix that in the next set.
> >
> > Done. The fix is part of 0001 now.
> >
> >
> >
> > >
> > > >
> > > > I will continue to review this feature from the user's perspective.  Thank you for working on it, I am very excited to get this in.
> > >
> >
> > here's patchset rebased on 792b2c7e6d926e61e8ff3b33d3e22d7d74e7a437
> > with conflicts in rowsecurity.sql/out fixed.
> >
> > >
> > > 0001 - 0005 are the same as the previous set.
> > > 0007 - has RLS tests. It is the same as 0006 from the previous patch set.
> >
> > This is same as the previous patchset.
> >
> > >
> > > 0006 - is new addressing collation and edge-vertex link qual creation.
> > > This patch adds code to store collation and typmod to
> > > pg_propgraph_property catalog and propagate it to property graph
> > > references in GRAPH_TABLE. Collation is used by
> > > assign_query_collations and assign_expr_collations to propagate
> > > collation up the query and expression tree respectively. typmod is
> > > used to report typmod of property reference from exprTypemod().
> > >
> > > While finishing code to create vertex-edge link quals, I found that we
> > > need to find and store the operator to be used for key matching in
> > > those quals. I think we have to do something similar to what primary
> > > key handling code does - find the equality operator when creating edge
> > > descriptor and store it in pg_propgraph_element. I am not sure whether
> > > we should add a dependency on the operator. I will look into this
> > > next.
> >
> > 0006 in the attached patch series completes this work. Now we find the
> > equality operators to be used for vertex-edge quals and save it in
> > pg_propgraph_element catalog and also add a dependency between the
> > edge element and the equality operators.
> >
> > 0008 - has WIP fix for \d and \d+
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat

I'm looking at the catalog definition, I have some questions which
might be silly.

Each pg element can have multiple labels(whose properties belong
to the same pg element), can we have multiple elements share the
same label?

If we have a 1..* relation between element and label, I think maybe
we don't need _pg_propgraph_label_.

From the name _pg_propgraph_label_property_, I tend to think it is
referencing _pg_propgraph_label_, but actually it is referencing
_pg_propgraph_element_label_.

-- 
Regards
Junwang Zhao

  27. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2024-12-16T10:14:04Z

    Hi Junwang,

>
> I'm looking at the catalog definition, I have some questions which
> might be silly.

Thanks for your interest in SQL/PGQ.

>
> Each pg element can have multiple labels(whose properties belong
> to the same pg element), can we have multiple elements share the
> same label?

Yes. A label can be shared between edges and vertices as well.

>
> If we have a 1..* relation between element and label, I think maybe
> we don't need _pg_propgraph_label_.

pg_propgraph_label is used to map a label name in a given property
graph to its OID. pg_propgraph_element_label - can be used to find all
the elements with a given label and all the labels of a given element.
The relationship is many to many.

>
> From the name _pg_propgraph_label_property_, I tend to think it is
> referencing _pg_propgraph_label_, but actually it is referencing
> _pg_propgraph_element_label_.
>

Right.

-- 
Best Wishes,
Ashutosh Bapat

  28. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2024-12-16T12:00:30Z

    On Mon, Dec 16, 2024 at 6:14 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Hi Junwang,
>
> >
> > I'm looking at the catalog definition, I have some questions which
> > might be silly.
>
> Thanks for your interest in SQL/PGQ.
>
> >
> > Each pg element can have multiple labels(whose properties belong
> > to the same pg element), can we have multiple elements share the
> > same label?
>
> Yes. A label can be shared between edges and vertices as well.
>
> >
> > If we have a 1..* relation between element and label, I think maybe
> > we don't need _pg_propgraph_label_.
>
> pg_propgraph_label is used to map a label name in a given property
> graph to its OID. pg_propgraph_element_label - can be used to find all
> the elements with a given label and all the labels of a given element.
> The relationship is many to many.

Ok, then it makes sense to me. Thanks for the explanation.

>
> >
> > From the name _pg_propgraph_label_property_, I tend to think it is
> > referencing _pg_propgraph_label_, but actually it is referencing
> > _pg_propgraph_element_label_.
> >
>
> Right.
>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  29. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2024-12-21T12:51:04Z

    Hi Ashutosh,

On Fri, Dec 6, 2024 at 12:34 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Sorry, I forgot to attach patches. PFA the patches.
>
> On Thu, Dec 5, 2024 at 4:38 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Fri, Nov 22, 2024 at 7:29 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Tue, Nov 19, 2024 at 10:08 PM Vik Fearing <vik@postgresfriends.org> wrote:
> > > >
> > > >
> > > > On 05/11/2024 16:41, Ashutosh Bapat wrote:
> > > >
> > > > On Wed, Aug 28, 2024 at 3:48 PM Ashutosh Bapat
> > > > <ashutosh.bapat.oss@gmail.com> wrote:
> > > >
> > > > Patches 0001 - 0006 are same as the previous set.
> > > > 0007 - fixes all the problems you reported till now and also the one I
> > > > found. The commit message describes the fixes in detail.
> > > >
> > > > Here's an updated patchset based on the latest HEAD.
> > > >
> > > >
> > > >
> > > > I have been looking at this patchset from a user's and standards' perspective and I am quite pleased with what I am seeing for the most part.  I have not been looking much at the code itself, although I do plan on reviewing some of the code in the future.
> > >
> > > Thanks for looking at the patches.
> > >
> > > >
> > > >
> > > > There are a few things that stick out to me.
> > > >
> > > >
> > > > 1.
> > > > I don't see any way to view the structure of of a property graph.  For example:
> > > >
> > > >
> > > > postgres=# CREATE TABLE objects (id INTEGER, color VARCHAR, shape VARCHAR, size INTEGER);
> > > > CREATE TABLE
> > > > postgres=# CREATE PROPERTY GRAPH propgraph VERTEX TABLES (objects KEY (id) PROPERTIES ALL COLUMNS);
> > > > CREATE PROPERTY GRAPH
> > > > postgres=# \dG propgraph
> > > >                       List of relations
> > > >       Schema       |   Name    |      Type      |    Owner
> > > > -------------------+-----------+----------------+-------------
> > > >  graph_table_tests | propgraph | property graph | vik.fearing
> > > > (1 row)
> > > >
> > > > postgres=# \d propgraph
> > > > Property graph "graph_table_tests.propgraph"
> > > >  Column | Type
> > > > --------+------
> > > >
> > > > I don't really know what to do with that.
> > >
> > > Yes. It is on my TODO list. IMO we should just print the first line
> > > property graph "...". There are no predefined columns in this
> > > relation. And somehow redirect them to use \dG instead.
> >
> > \d+ propgraph prints the definition of property graph. I find \dG
> > similar to \di which doesn't print the structure of an index. Instead
> > \d+ <index name> prints it.
> >
> > In the attached patch series I have added patch 0008 to remove
> > unnecessary header
> > > >  Column | Type
> > > > --------+------
> >
> > It still prints an extra line but I haven't found a way to eliminate
> > it. Hence 0008 is WIP. I have listed TODOs in the commit message of
> > that patch.
> >
> >
> > > >
> > > >
> > > > 2.
> > > > There is a missing newline in the \? help of psql.
> > > >     HELP0("  \\dFt[+] [PATTERN]      list text search templates\n");
> > > >     HELP0("  \\dg[S+] [PATTERN]      list roles\n");
> > > >     HELP0("  \\dG[S+] [PATTERN]      list property graphs");   <---
> > > >     HELP0("  \\di[S+] [PATTERN]      list indexes\n");
> > > >     HELP0("  \\dl[+]                 list large objects, same as \\lo_list\n");
> > > >
> > >
> > > Will fix that in the next set.
> >
> > Done. The fix is part of 0001 now.
> >
> >
> >
> > >
> > > >
> > > > I will continue to review this feature from the user's perspective.  Thank you for working on it, I am very excited to get this in.
> > >
> >
> > here's patchset rebased on 792b2c7e6d926e61e8ff3b33d3e22d7d74e7a437
> > with conflicts in rowsecurity.sql/out fixed.
> >
> > >
> > > 0001 - 0005 are the same as the previous set.
> > > 0007 - has RLS tests. It is the same as 0006 from the previous patch set.
> >
> > This is same as the previous patchset.
> >
> > >
> > > 0006 - is new addressing collation and edge-vertex link qual creation.
> > > This patch adds code to store collation and typmod to
> > > pg_propgraph_property catalog and propagate it to property graph
> > > references in GRAPH_TABLE. Collation is used by
> > > assign_query_collations and assign_expr_collations to propagate
> > > collation up the query and expression tree respectively. typmod is
> > > used to report typmod of property reference from exprTypemod().
> > >
> > > While finishing code to create vertex-edge link quals, I found that we
> > > need to find and store the operator to be used for key matching in
> > > those quals. I think we have to do something similar to what primary
> > > key handling code does - find the equality operator when creating edge
> > > descriptor and store it in pg_propgraph_element. I am not sure whether
> > > we should add a dependency on the operator. I will look into this
> > > next.
> >
> > 0006 in the attached patch series completes this work. Now we find the
> > equality operators to be used for vertex-edge quals and save it in
> > pg_propgraph_element catalog and also add a dependency between the
> > edge element and the equality operators.
> >
> > 0008 - has WIP fix for \d and \d+
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat

Here are some review opinions for 0001, I haven't seen the other
patches, forgive me if some of the opinions have already been
addressed.

1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
the fk pointer will always point to last ForeignKeyCacheInfo of
the edge relation, which is wrong. We should add another pointer
that remembers the matched ForeignKeyCacheInfo to ref_rel. See
attached 0001.

2. Some of the TODOs seem easy to address, attached 0002 does this.

3. Since property name and label name are unique in property graph
scope, some of the wording are not accurate. See attached 0003.

-- 
Regards
Junwang Zhao

  30. Re: SQL Property Graph Queries (SQL/PGQ)

    Andreas Karlsson <andreas@proxel.se> — 2024-12-21T21:45:25Z

    On 10/29/24 8:55 PM, Andreas Karlsson wrote:
> I especially dislike the static variable in our patch. And as far as I 
> understand it you can avoid the static by changing the lexer to use the 
> push parser so it can emit multiple terminal tokens from one parsed 
> token, but I have not looked into push parsers and have no idea how this 
> would affect performance.

Updated the patch to remove the static variable. No clue why I thought 
that one was necessary.

Andreas

  31. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-01-01T08:52:29Z

    On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
Thanks Junwang for your review.

> Here are some review opinions for 0001, I haven't seen the other
> patches, forgive me if some of the opinions have already been
> addressed.
>
> 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> the fk pointer will always point to last ForeignKeyCacheInfo of
> the edge relation, which is wrong. We should add another pointer
> that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> attached 0001.

Nice catch. I fixed it in a slightly different way reducing overall
code by using foreach_node(). I have merged this as part of 0004 which
has fixes for several other issues. Interestingly there was a SQL that
had revealed the problem in create_property_graph.sql. But we had
accepted a wrong output. Corrected that as well.

>
> 2. Some of the TODOs seem easy to address, attached 0002 does this.

From a cursory glance those changes look useful and mostly correct. It
will be good if you can provide a SQL test for those, covering that
part of the code. Please post the whole patch-set with your changes as
a separate commit/patch.

>
> 3. Since property name and label name are unique in property graph
> scope, some of the wording are not accurate. See attached 0003.

     <para>
-      For each property graph element, all properties with the same name must
-      have the same expression for each label.  For example, this would be
+      For each property graph, all properties with the same name must
+      have the same expression.  For example, this would be

Each property graph element may have a property with the same name
associated with multiple labels. But each of those properties should
have the same expression. You may see that as the same property being
defined multiple times once in each label it is associated with OR
multiple properties with the same name. Current wording uses the
latter notion, so it looks fine to me. The changes made to error
messages are not needed with this notion.


--
Best Wishes,
Ashutosh Bapat

  32. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-01-01T09:01:59Z

    On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> Thanks Junwang for your review.
>
> > Here are some review opinions for 0001, I haven't seen the other
> > patches, forgive me if some of the opinions have already been
> > addressed.
> >
> > 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> > the fk pointer will always point to last ForeignKeyCacheInfo of
> > the edge relation, which is wrong. We should add another pointer
> > that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> > attached 0001.
>
> Nice catch. I fixed it in a slightly different way reducing overall
> code by using foreach_node(). I have merged this as part of 0004 which
> has fixes for several other issues. Interestingly there was a SQL that
> had revealed the problem in create_property_graph.sql. But we had
> accepted a wrong output. Corrected that as well.
>
> >
> > 2. Some of the TODOs seem easy to address, attached 0002 does this.
>
> From a cursory glance those changes look useful and mostly correct. It
> will be good if you can provide a SQL test for those, covering that
> part of the code. Please post the whole patch-set with your changes as
> a separate commit/patch.
>
> >
> > 3. Since property name and label name are unique in property graph
> > scope, some of the wording are not accurate. See attached 0003.
>
>      <para>
> -      For each property graph element, all properties with the same name must
> -      have the same expression for each label.  For example, this would be
> +      For each property graph, all properties with the same name must
> +      have the same expression.  For example, this would be
>
> Each property graph element may have a property with the same name
> associated with multiple labels. But each of those properties should
> have the same expression. You may see that as the same property being
> defined multiple times once in each label it is associated with OR
> multiple properties with the same name. Current wording uses the
> latter notion, so it looks fine to me. The changes made to error
> messages are not needed with this notion.

My last email is held for moderation. It will arrive once moderators
release it. In the meantime trying to send the patches as a zip file
in a hope that it won't require moderation.

-- 
Best Wishes,
Ashutosh Bapat

  33. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-01-19T13:15:45Z

    Hi Ashutosh,

On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > Thanks Junwang for your review.
> >
> > > Here are some review opinions for 0001, I haven't seen the other
> > > patches, forgive me if some of the opinions have already been
> > > addressed.
> > >
> > > 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> > > the fk pointer will always point to last ForeignKeyCacheInfo of
> > > the edge relation, which is wrong. We should add another pointer
> > > that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> > > attached 0001.
> >
> > Nice catch. I fixed it in a slightly different way reducing overall
> > code by using foreach_node(). I have merged this as part of 0004 which
> > has fixes for several other issues. Interestingly there was a SQL that
> > had revealed the problem in create_property_graph.sql. But we had
> > accepted a wrong output. Corrected that as well.
> >
> > >
> > > 2. Some of the TODOs seem easy to address, attached 0002 does this.
> >
> > From a cursory glance those changes look useful and mostly correct. It
> > will be good if you can provide a SQL test for those, covering that
> > part of the code. Please post the whole patch-set with your changes as
> > a separate commit/patch.
> >
> > >
> > > 3. Since property name and label name are unique in property graph
> > > scope, some of the wording are not accurate. See attached 0003.
> >
> >      <para>
> > -      For each property graph element, all properties with the same name must
> > -      have the same expression for each label.  For example, this would be
> > +      For each property graph, all properties with the same name must
> > +      have the same expression.  For example, this would be
> >
> > Each property graph element may have a property with the same name
> > associated with multiple labels. But each of those properties should
> > have the same expression. You may see that as the same property being
> > defined multiple times once in each label it is associated with OR
> > multiple properties with the same name. Current wording uses the
> > latter notion, so it looks fine to me. The changes made to error
> > messages are not needed with this notion.
>
> My last email is held for moderation. It will arrive once moderators
> release it. In the meantime trying to send the patches as a zip file
> in a hope that it won't require moderation.
>
> --
> Best Wishes,
> Ashutosh Bapat

0007-RLS-tests-20250101.patch introduces regression test failure:

+WARNING:  outfuncs/readfuncs failed to produce an equal rewritten parse tree

P.S. It seems the patch set doesn't apply to master.

-- 
Regards
Junwang Zhao

  34. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-01-24T13:36:11Z

    On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Ashutosh,
>
> On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > Thanks Junwang for your review.
> > >
> > > > Here are some review opinions for 0001, I haven't seen the other
> > > > patches, forgive me if some of the opinions have already been
> > > > addressed.
> > > >
> > > > 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> > > > the fk pointer will always point to last ForeignKeyCacheInfo of
> > > > the edge relation, which is wrong. We should add another pointer
> > > > that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> > > > attached 0001.
> > >
> > > Nice catch. I fixed it in a slightly different way reducing overall
> > > code by using foreach_node(). I have merged this as part of 0004 which
> > > has fixes for several other issues. Interestingly there was a SQL that
> > > had revealed the problem in create_property_graph.sql. But we had
> > > accepted a wrong output. Corrected that as well.
> > >
> > > >
> > > > 2. Some of the TODOs seem easy to address, attached 0002 does this.
> > >
> > > From a cursory glance those changes look useful and mostly correct. It
> > > will be good if you can provide a SQL test for those, covering that
> > > part of the code. Please post the whole patch-set with your changes as
> > > a separate commit/patch.
> > >
> > > >
> > > > 3. Since property name and label name are unique in property graph
> > > > scope, some of the wording are not accurate. See attached 0003.
> > >
> > >      <para>
> > > -      For each property graph element, all properties with the same name must
> > > -      have the same expression for each label.  For example, this would be
> > > +      For each property graph, all properties with the same name must
> > > +      have the same expression.  For example, this would be
> > >
> > > Each property graph element may have a property with the same name
> > > associated with multiple labels. But each of those properties should
> > > have the same expression. You may see that as the same property being
> > > defined multiple times once in each label it is associated with OR
> > > multiple properties with the same name. Current wording uses the
> > > latter notion, so it looks fine to me. The changes made to error
> > > messages are not needed with this notion.
> >
> > My last email is held for moderation. It will arrive once moderators
> > release it. In the meantime trying to send the patches as a zip file
> > in a hope that it won't require moderation.
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
> 0007-RLS-tests-20250101.patch introduces regression test failure:
>
> +WARNING:  outfuncs/readfuncs failed to produce an equal rewritten parse tree
>
> P.S. It seems the patch set doesn't apply to master.

Thanks for noticing it.

Here's rebased patch set on the current head with some minor conflicts
in various files fixed. I did not see the said failure on my laptop.

0001-0009 patches are the same as the previous set sans mergeconflict fixes.
0010 - is test for \dGx - to make sure that the extended format output
works with \dG. We may decide not to have this patch in the final
commit. But no harm in being there til that point.

-- 
Best Wishes,
Ashutosh Bapat

  35. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-01-24T15:46:30Z

    On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > Hi Ashutosh,
> >
> > On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
> > > <ashutosh.bapat.oss@gmail.com> wrote:
> > > >
> > > > On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > > Thanks Junwang for your review.
> > > >
> > > > > Here are some review opinions for 0001, I haven't seen the other
> > > > > patches, forgive me if some of the opinions have already been
> > > > > addressed.
> > > > >
> > > > > 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> > > > > the fk pointer will always point to last ForeignKeyCacheInfo of
> > > > > the edge relation, which is wrong. We should add another pointer
> > > > > that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> > > > > attached 0001.
> > > >
> > > > Nice catch. I fixed it in a slightly different way reducing overall
> > > > code by using foreach_node(). I have merged this as part of 0004 which
> > > > has fixes for several other issues. Interestingly there was a SQL that
> > > > had revealed the problem in create_property_graph.sql. But we had
> > > > accepted a wrong output. Corrected that as well.
> > > >
> > > > >
> > > > > 2. Some of the TODOs seem easy to address, attached 0002 does this.
> > > >
> > > > From a cursory glance those changes look useful and mostly correct. It
> > > > will be good if you can provide a SQL test for those, covering that
> > > > part of the code. Please post the whole patch-set with your changes as
> > > > a separate commit/patch.
> > > >
> > > > >
> > > > > 3. Since property name and label name are unique in property graph
> > > > > scope, some of the wording are not accurate. See attached 0003.
> > > >
> > > >      <para>
> > > > -      For each property graph element, all properties with the same name must
> > > > -      have the same expression for each label.  For example, this would be
> > > > +      For each property graph, all properties with the same name must
> > > > +      have the same expression.  For example, this would be
> > > >
> > > > Each property graph element may have a property with the same name
> > > > associated with multiple labels. But each of those properties should
> > > > have the same expression. You may see that as the same property being
> > > > defined multiple times once in each label it is associated with OR
> > > > multiple properties with the same name. Current wording uses the
> > > > latter notion, so it looks fine to me. The changes made to error
> > > > messages are not needed with this notion.
> > >
> > > My last email is held for moderation. It will arrive once moderators
> > > release it. In the meantime trying to send the patches as a zip file
> > > in a hope that it won't require moderation.
> > >
> > > --
> > > Best Wishes,
> > > Ashutosh Bapat
> >
> > 0007-RLS-tests-20250101.patch introduces regression test failure:
> >
> > +WARNING:  outfuncs/readfuncs failed to produce an equal rewritten parse tree
> >
> > P.S. It seems the patch set doesn't apply to master.
>
> Thanks for noticing it.
>
> Here's rebased patch set on the current head with some minor conflicts
> in various files fixed. I did not see the said failure on my laptop.

I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
removing this option clears the warning, but I'm not sure if this is a
hidden issue.

>
> 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> 0010 - is test for \dGx - to make sure that the extended format output
> works with \dG. We may decide not to have this patch in the final
> commit. But no harm in being there til that point.

I have some changes based on the latest patch set. I attached two patches with
the following summary.

0001:
- doc: some of the query in ddl.sgml can not be executed
- after path factor was introduced, some comments doesn't apply

0002:
- add a get_propgraph_element_alias_name function and do some trivial refactor

> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  36. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-01-24T15:56:06Z

    On Fri, Jan 24, 2025 at 11:46 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> > > <ashutosh.bapat.oss@gmail.com> wrote:
> > > >
> > > > On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
> > > > <ashutosh.bapat.oss@gmail.com> wrote:
> > > > >
> > > > > On Sat, Dec 21, 2024 at 6:21 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > > > Thanks Junwang for your review.
> > > > >
> > > > > > Here are some review opinions for 0001, I haven't seen the other
> > > > > > patches, forgive me if some of the opinions have already been
> > > > > > addressed.
> > > > > >
> > > > > > 1. In propgraph_edge_get_ref_keys, when finding a matching foreign key,
> > > > > > the fk pointer will always point to last ForeignKeyCacheInfo of
> > > > > > the edge relation, which is wrong. We should add another pointer
> > > > > > that remembers the matched ForeignKeyCacheInfo to ref_rel. See
> > > > > > attached 0001.
> > > > >
> > > > > Nice catch. I fixed it in a slightly different way reducing overall
> > > > > code by using foreach_node(). I have merged this as part of 0004 which
> > > > > has fixes for several other issues. Interestingly there was a SQL that
> > > > > had revealed the problem in create_property_graph.sql. But we had
> > > > > accepted a wrong output. Corrected that as well.
> > > > >
> > > > > >
> > > > > > 2. Some of the TODOs seem easy to address, attached 0002 does this.
> > > > >
> > > > > From a cursory glance those changes look useful and mostly correct. It
> > > > > will be good if you can provide a SQL test for those, covering that
> > > > > part of the code. Please post the whole patch-set with your changes as
> > > > > a separate commit/patch.
> > > > >
> > > > > >
> > > > > > 3. Since property name and label name are unique in property graph
> > > > > > scope, some of the wording are not accurate. See attached 0003.
> > > > >
> > > > >      <para>
> > > > > -      For each property graph element, all properties with the same name must
> > > > > -      have the same expression for each label.  For example, this would be
> > > > > +      For each property graph, all properties with the same name must
> > > > > +      have the same expression.  For example, this would be
> > > > >
> > > > > Each property graph element may have a property with the same name
> > > > > associated with multiple labels. But each of those properties should
> > > > > have the same expression. You may see that as the same property being
> > > > > defined multiple times once in each label it is associated with OR
> > > > > multiple properties with the same name. Current wording uses the
> > > > > latter notion, so it looks fine to me. The changes made to error
> > > > > messages are not needed with this notion.
> > > >
> > > > My last email is held for moderation. It will arrive once moderators
> > > > release it. In the meantime trying to send the patches as a zip file
> > > > in a hope that it won't require moderation.
> > > >
> > > > --
> > > > Best Wishes,
> > > > Ashutosh Bapat
> > >
> > > 0007-RLS-tests-20250101.patch introduces regression test failure:
> > >
> > > +WARNING:  outfuncs/readfuncs failed to produce an equal rewritten parse tree
> > >
> > > P.S. It seems the patch set doesn't apply to master.
> >
> > Thanks for noticing it.
> >
> > Here's rebased patch set on the current head with some minor conflicts
> > in various files fixed. I did not see the said failure on my laptop.
>
> I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> removing this option clears the warning, but I'm not sure if this is a
> hidden issue.

Cirrus meson FreeBSD build has this setting, the regression test
rowsecurity failed
the same as my local machine, see [0], so I think this is an issue we
have to resolve.

Cirrus meson Bookworm build failed 002_pg_upgrade.pl and 027_stream_regress.pl,
see [1]

[0] https://cirrus-ci.com/task/5702052891852800
[1] https://cirrus-ci.com/task/6265002845274112

>
> >
> > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > 0010 - is test for \dGx - to make sure that the extended format output
> > works with \dG. We may decide not to have this patch in the final
> > commit. But no harm in being there til that point.
>
> I have some changes based on the latest patch set. I attached two patches with
> the following summary.
>
> 0001:
> - doc: some of the query in ddl.sgml can not be executed
> - after path factor was introduced, some comments doesn't apply
>
> 0002:
> - add a get_propgraph_element_alias_name function and do some trivial refactor
>
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Regards
> Junwang Zhao



-- 
Regards
Junwang Zhao

  37. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-01-28T10:26:45Z

    On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> removing this option clears the warning, but I'm not sure if this is a
> hidden issue.
>

Thanks for the hint. I found the issue and the fix appears in 0004.
Some members of RangeTblEntry were not being handled in read/out
functions.

> >
> > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > 0010 - is test for \dGx - to make sure that the extended format output
> > works with \dG. We may decide not to have this patch in the final
> > commit. But no harm in being there til that point.
>
> I have some changes based on the latest patch set. I attached two patches with
> the following summary.
>
> 0001:
> - doc: some of the query in ddl.sgml can not be executed

The standard seems to require a property reference to be qualified by
element pattern variable, even if the property is referenced within
the same element pattern bound to the variable. Hence I accepted your
document fixes which qualify property reference with element pattern
variable.

However, I didn't understand why you changed a LABEL name from order to order_.

> - after path factor was introduced, some comments doesn't apply

Thanks pointing those out. Accepted after rephrasing those and also
correcting some related comments.

>
> 0002:
> - add a get_propgraph_element_alias_name function and do some trivial refactor
>

I see you have added some negative tests - object not found tests, but
I didn't see positive tests. Hence I haven't added those changes in
the attached patchset. But we certainly need those changes. You may
want to submit a patch with positive tests. That code needs to be
fixed before committing anyway.


--
Best Wishes,
Ashutosh Bapat

  38. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-01-28T11:01:41Z

    On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> > removing this option clears the warning, but I'm not sure if this is a
> > hidden issue.
> >
>
> Thanks for the hint. I found the issue and the fix appears in 0004.
> Some members of RangeTblEntry were not being handled in read/out
> functions.

Thanks for the fix, I will apply and test again.

>
> > >
> > > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > > 0010 - is test for \dGx - to make sure that the extended format output
> > > works with \dG. We may decide not to have this patch in the final
> > > commit. But no harm in being there til that point.
> >
> > I have some changes based on the latest patch set. I attached two patches with
> > the following summary.
> >
> > 0001:
> > - doc: some of the query in ddl.sgml can not be executed
>
> The standard seems to require a property reference to be qualified by
> element pattern variable, even if the property is referenced within
> the same element pattern bound to the variable. Hence I accepted your
> document fixes which qualify property reference with element pattern
> variable.
>
> However, I didn't understand why you changed a LABEL name from order to order_.

Ah, that's because `order` is a keyword of SQL(order by), so the alias
is a conflict.
I'm not saying `order_` is a good name though.

>
> > - after path factor was introduced, some comments doesn't apply
>
> Thanks pointing those out. Accepted after rephrasing those and also
> correcting some related comments.
>
> >
> > 0002:
> > - add a get_propgraph_element_alias_name function and do some trivial refactor
> >
>
> I see you have added some negative tests - object not found tests, but
> I didn't see positive tests. Hence I haven't added those changes in
> the attached patchset. But we certainly need those changes. You may
> want to submit a patch with positive tests. That code needs to be
> fixed before committing anyway.

Ok, I'll add positive tests.

>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  39. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-01-28T11:03:19Z

    On Tue, Jan 28, 2025 at 4:31 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > >
> > > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> > > removing this option clears the warning, but I'm not sure if this is a
> > > hidden issue.
> > >
> >
> > Thanks for the hint. I found the issue and the fix appears in 0004.
> > Some members of RangeTblEntry were not being handled in read/out
> > functions.
>
> Thanks for the fix, I will apply and test again.
>
> >
> > > >
> > > > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > > > 0010 - is test for \dGx - to make sure that the extended format output
> > > > works with \dG. We may decide not to have this patch in the final
> > > > commit. But no harm in being there til that point.
> > >
> > > I have some changes based on the latest patch set. I attached two patches with
> > > the following summary.
> > >
> > > 0001:
> > > - doc: some of the query in ddl.sgml can not be executed
> >
> > The standard seems to require a property reference to be qualified by
> > element pattern variable, even if the property is referenced within
> > the same element pattern bound to the variable. Hence I accepted your
> > document fixes which qualify property reference with element pattern
> > variable.
> >
> > However, I didn't understand why you changed a LABEL name from order to order_.
>
> Ah, that's because `order` is a keyword of SQL(order by), so the alias
> is a conflict.
> I'm not saying `order_` is a good name though.

I didn't realize that. Thanks for catching. In that case just orders
or cust_orders?

>
> >
> > > - after path factor was introduced, some comments doesn't apply
> >
> > Thanks pointing those out. Accepted after rephrasing those and also
> > correcting some related comments.
> >
> > >
> > > 0002:
> > > - add a get_propgraph_element_alias_name function and do some trivial refactor
> > >
> >
> > I see you have added some negative tests - object not found tests, but
> > I didn't see positive tests. Hence I haven't added those changes in
> > the attached patchset. But we certainly need those changes. You may
> > want to submit a patch with positive tests. That code needs to be
> > fixed before committing anyway.
>
> Ok, I'll add positive tests.

Thanks.

-- 
Best Wishes,
Ashutosh Bapat

  40. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-01-28T11:16:30Z

    On Tue, Jan 28, 2025 at 7:03 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Jan 28, 2025 at 4:31 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > >
> > > > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> > > > removing this option clears the warning, but I'm not sure if this is a
> > > > hidden issue.
> > > >
> > >
> > > Thanks for the hint. I found the issue and the fix appears in 0004.
> > > Some members of RangeTblEntry were not being handled in read/out
> > > functions.
> >
> > Thanks for the fix, I will apply and test again.
> >
> > >
> > > > >
> > > > > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > > > > 0010 - is test for \dGx - to make sure that the extended format output
> > > > > works with \dG. We may decide not to have this patch in the final
> > > > > commit. But no harm in being there til that point.
> > > >
> > > > I have some changes based on the latest patch set. I attached two patches with
> > > > the following summary.
> > > >
> > > > 0001:
> > > > - doc: some of the query in ddl.sgml can not be executed
> > >
> > > The standard seems to require a property reference to be qualified by
> > > element pattern variable, even if the property is referenced within
> > > the same element pattern bound to the variable. Hence I accepted your
> > > document fixes which qualify property reference with element pattern
> > > variable.
> > >
> > > However, I didn't understand why you changed a LABEL name from order to order_.
> >
> > Ah, that's because `order` is a keyword of SQL(order by), so the alias
> > is a conflict.
> > I'm not saying `order_` is a good name though.
>
> I didn't realize that. Thanks for catching. In that case just orders
> or cust_orders?

Yeah, I think explicitly LABELed as `orders` makes sense.

>
> >
> > >
> > > > - after path factor was introduced, some comments doesn't apply
> > >
> > > Thanks pointing those out. Accepted after rephrasing those and also
> > > correcting some related comments.
> > >
> > > >
> > > > 0002:
> > > > - add a get_propgraph_element_alias_name function and do some trivial refactor
> > > >
> > >
> > > I see you have added some negative tests - object not found tests, but
> > > I didn't see positive tests. Hence I haven't added those changes in
> > > the attached patchset. But we certainly need those changes. You may
> > > want to submit a patch with positive tests. That code needs to be
> > > fixed before committing anyway.
> >
> > Ok, I'll add positive tests.
>
> Thanks.
>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  41. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-02-06T14:52:32Z

    Hi Ashutosh,

On Tue, Jan 28, 2025 at 6:17 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Fri, Jan 24, 2025 at 9:16 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > I figured out it's because I have `-DWRITE_READ_PARSE_PLAN_TREES` this option,
> > removing this option clears the warning, but I'm not sure if this is a
> > hidden issue.
> >
>
> Thanks for the hint. I found the issue and the fix appears in 0004.
> Some members of RangeTblEntry were not being handled in read/out
> functions.
>
> > >
> > > 0001-0009 patches are the same as the previous set sans mergeconflict fixes.
> > > 0010 - is test for \dGx - to make sure that the extended format output
> > > works with \dG. We may decide not to have this patch in the final
> > > commit. But no harm in being there til that point.
> >
> > I have some changes based on the latest patch set. I attached two patches with
> > the following summary.
> >
> > 0001:
> > - doc: some of the query in ddl.sgml can not be executed
>
> The standard seems to require a property reference to be qualified by
> element pattern variable, even if the property is referenced within
> the same element pattern bound to the variable. Hence I accepted your
> document fixes which qualify property reference with element pattern
> variable.
>
> However, I didn't understand why you changed a LABEL name from order to order_.
>
> > - after path factor was introduced, some comments doesn't apply
>
> Thanks pointing those out. Accepted after rephrasing those and also
> correcting some related comments.
>
> >
> > 0002:
> > - add a get_propgraph_element_alias_name function and do some trivial refactor
> >
>
> I see you have added some negative tests - object not found tests, but
> I didn't see positive tests. Hence I haven't added those changes in
> the attached patchset. But we certainly need those changes. You may
> want to submit a patch with positive tests. That code needs to be
> fixed before committing anyway.

The attached file adds the positive tests.

>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  42. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-02-10T06:14:00Z

    On Thu, Feb 6, 2025 at 8:22 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > >
> >
> > I see you have added some negative tests - object not found tests, but
> > I didn't see positive tests. Hence I haven't added those changes in
> > the attached patchset. But we certainly need those changes. You may
> > want to submit a patch with positive tests. That code needs to be
> > fixed before committing anyway.
>
> The attached file adds the positive tests.

Hi Junwang,
Thanks for the patch, but please post it as a separate patch in the
full patch-set, otherwise CFBot gets confused.

-- 
Best Wishes,
Ashutosh Bapat

  43. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-02-10T15:00:05Z

    Hi Ashutosh,

On Mon, Feb 10, 2025 at 2:14 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Thu, Feb 6, 2025 at 8:22 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > >
> > >
> > > I see you have added some negative tests - object not found tests, but
> > > I didn't see positive tests. Hence I haven't added those changes in
> > > the attached patchset. But we certainly need those changes. You may
> > > want to submit a patch with positive tests. That code needs to be
> > > fixed before committing anyway.
> >
> > The attached file adds the positive tests.
>
> Hi Junwang,
> Thanks for the patch, but please post it as a separate patch in the
> full patch-set, otherwise CFBot gets confused.

Ok, see the attached.

0001-0009 are the original patches of 20250127 with rebase of master
0010 fix ci error due to `Show more-intuitive titles for psql
commands`, see a14707da564e
0011 fix ci error due to unstable collation tests, we should not
depend on pg_catalog."default", I observed 002_pg_upgrade.pl failure
caused by this.
0012 trivial refactor of property graph object address

>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  44. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-02-23T12:54:53Z

    On Mon, Feb 10, 2025 at 11:00 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Ashutosh,
>
> On Mon, Feb 10, 2025 at 2:14 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Thu, Feb 6, 2025 at 8:22 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > > >
> > > >
> > > > I see you have added some negative tests - object not found tests, but
> > > > I didn't see positive tests. Hence I haven't added those changes in
> > > > the attached patchset. But we certainly need those changes. You may
> > > > want to submit a patch with positive tests. That code needs to be
> > > > fixed before committing anyway.
> > >
> > > The attached file adds the positive tests.
> >
> > Hi Junwang,
> > Thanks for the patch, but please post it as a separate patch in the
> > full patch-set, otherwise CFBot gets confused.
>
> Ok, see the attached.
>
> 0001-0009 are the original patches of 20250127 with rebase of master
> 0010 fix ci error due to `Show more-intuitive titles for psql
> commands`, see a14707da564e
> 0011 fix ci error due to unstable collation tests, we should not
> depend on pg_catalog."default", I observed 002_pg_upgrade.pl failure
> caused by this.
> 0012 trivial refactor of property graph object address
>
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Regards
> Junwang Zhao

Here is v11 with another trivial refactor, I add a seperate patch file 0013, in
insert_property_record, there is no need to check `type`, `typmode` and
`collation` if the property doesn't exists before, in AlterPropGraph, there is
no need to call `check_all_labels_properties` for each added vertex or edge.

Other files remain unchanged except I’ve added some missing document and
typo fix we discussed in the list but not included in the previous
patch, I included
them in 0008.

-- 
Regards
Junwang Zhao

  45. Re: SQL Property Graph Queries (SQL/PGQ)

    Vladlen Popolitov <v.popolitov@postgrespro.ru> — 2025-02-25T09:47:39Z

    Hi!

  I would ask about CREATE GRAPH PROPERTY. From my point of view it makes 
very strong
check of types including check of typmod.

  Example:

CREATE TABLE userslist (
   user_id INT primary key,
   name   VARCHAR(40)
);

CREATE TABLE groupslist (
   group_id INT primary key,
   name   VARCHAR(30)
);

CREATE TABLE memberslist (
  member_id INT primary key,
  user_id INT,
  group_id INT,
  CONSTRAINT members_users_fk1 FOREIGN KEY (user_id) REFERENCES userslist 
(user_id),
  CONSTRAINT members_groups_fk1 FOREIGN KEY (group_id) REFERENCES 
groupslist (group_id)
);

CREATE PROPERTY GRAPH members_pg
   VERTEX TABLES (
     userslist
       KEY (user_id)
       LABEL luser
       PROPERTIES ALL COLUMNS,
     groupslist
       KEY (group_id)
       LABEL lgroup
       PROPERTIES ALL COLUMNS
  )
   edge TABLES (
     memberslist
       KEY (member_id)
       SOURCE KEY (user_id) REFERENCES userslist (user_id)
       DESTINATION KEY (group_id) REFERENCES groupslist (group_id)
       LABEL lmember
       PROPERTIES ALL COLUMNS
  );

Last command fails with error:
ERROR:  property "name" data type modifier mismatch: 19 vs. 14
DETAIL:  In a property graph, a property of the same name has to have
the same type modifier in each label.

Labels luser and lgroup both have property "name" originated from tables 
userslist and groupslist
with types VARCHAR(40) and VARCHAR(30). Current implementation treats 
them as fields with
different types. I think, they should not be treated as different types. 
Typmod is additional
constrain, it does not create another type.
Documentation includes:"modifiers, that is optional constraints attached 
to a type declaration,
such as char(5) or numeric(30,2)"

Operations with values using different typmod do not require cast, they  
treated as the
same type.

Also I would add, that Oracle executes the code above without error.

I propose to exclude the check of typmod from the equivalence of types 
check in
src/backend/commands/propgraphcmds.c .

I suppose there is other reason to make this check (not the Standart 
SQL-2023 requirement,
but internal dependency), but I have not realised this reason.

-- 
Best regards,

Vladlen Popolitov.

  46. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-02-25T10:20:08Z

    On Tue, Feb 25, 2025 at 3:17 PM Vladlen Popolitov
<v.popolitov@postgrespro.ru> wrote:
>
> Hi!
>
>   I would ask about CREATE GRAPH PROPERTY. From my point of view it makes
> very strong
> check of types including check of typmod.
>
>   Example:
>
> CREATE TABLE userslist (
>    user_id INT primary key,
>    name   VARCHAR(40)
> );
>
> CREATE TABLE groupslist (
>    group_id INT primary key,
>    name   VARCHAR(30)
> );
>
> CREATE TABLE memberslist (
>   member_id INT primary key,
>   user_id INT,
>   group_id INT,
>   CONSTRAINT members_users_fk1 FOREIGN KEY (user_id) REFERENCES userslist
> (user_id),
>   CONSTRAINT members_groups_fk1 FOREIGN KEY (group_id) REFERENCES
> groupslist (group_id)
> );
>
> CREATE PROPERTY GRAPH members_pg
>    VERTEX TABLES (
>      userslist
>        KEY (user_id)
>        LABEL luser
>        PROPERTIES ALL COLUMNS,
>      groupslist
>        KEY (group_id)
>        LABEL lgroup
>        PROPERTIES ALL COLUMNS
>   )
>    edge TABLES (
>      memberslist
>        KEY (member_id)
>        SOURCE KEY (user_id) REFERENCES userslist (user_id)
>        DESTINATION KEY (group_id) REFERENCES groupslist (group_id)
>        LABEL lmember
>        PROPERTIES ALL COLUMNS
>   );
>
> Last command fails with error:
> ERROR:  property "name" data type modifier mismatch: 19 vs. 14
> DETAIL:  In a property graph, a property of the same name has to have
> the same type modifier in each label.
>
> Labels luser and lgroup both have property "name" originated from tables
> userslist and groupslist
> with types VARCHAR(40) and VARCHAR(30). Current implementation treats
> them as fields with
> different types. I think, they should not be treated as different types.
> Typmod is additional
> constrain, it does not create another type.
> Documentation includes:"modifiers, that is optional constraints attached
> to a type declaration,
> such as char(5) or numeric(30,2)"
>
> Operations with values using different typmod do not require cast, they
> treated as the
> same type.

When a property is projected in a COLUMNS clause, it will be added to
the SELECT list of the rewritten query, which in turn could be a UNION
query. Having the same typmod for all the properties with the same
name makes it easy to write the SELECT list of UNION. Otherwise, we
have to find a common typmod for all the properties. This restriction
is not expected to be permanent but makes the first set of patches
easy, which are quite large as is. I think in some next version, we
will lift this restriction as well as lift the restriction on all
properties with the same name needing the same datatype. According to
the SQL standard, they can be of different data types as long as
there's a common type to which they all can be cast to. It may be
possible to lift this restriction in this version itself, if we find
enough developer and reviewer bandwidth.


-- 
Best Wishes,
Ashutosh Bapat

  47. Re: SQL Property Graph Queries (SQL/PGQ)

    Vladlen Popolitov <v.popolitov@postgrespro.ru> — 2025-02-25T11:21:12Z

    Ashutosh Bapat писал(а) 2025-02-25 17:20:
> On Tue, Feb 25, 2025 at 3:17 PM Vladlen Popolitov
> <v.popolitov@postgrespro.ru> wrote:
>> 
>> Hi!
>> 
>>   I would ask about CREATE GRAPH PROPERTY. From my point of view it 
>> makes
>> very strong
>> check of types including check of typmod.
>> 
>>   Example:
>> 
>> CREATE TABLE userslist (
>>    user_id INT primary key,
>>    name   VARCHAR(40)
>> );
>> 
>> CREATE TABLE groupslist (
>>    group_id INT primary key,
>>    name   VARCHAR(30)
>> );
>> 
>> CREATE TABLE memberslist (
>>   member_id INT primary key,
>>   user_id INT,
>>   group_id INT,
>>   CONSTRAINT members_users_fk1 FOREIGN KEY (user_id) REFERENCES 
>> userslist
>> (user_id),
>>   CONSTRAINT members_groups_fk1 FOREIGN KEY (group_id) REFERENCES
>> groupslist (group_id)
>> );
>> 
>> CREATE PROPERTY GRAPH members_pg
>>    VERTEX TABLES (
>>      userslist
>>        KEY (user_id)
>>        LABEL luser
>>        PROPERTIES ALL COLUMNS,
>>      groupslist
>>        KEY (group_id)
>>        LABEL lgroup
>>        PROPERTIES ALL COLUMNS
>>   )
>>    edge TABLES (
>>      memberslist
>>        KEY (member_id)
>>        SOURCE KEY (user_id) REFERENCES userslist (user_id)
>>        DESTINATION KEY (group_id) REFERENCES groupslist (group_id)
>>        LABEL lmember
>>        PROPERTIES ALL COLUMNS
>>   );
>> 
>> Last command fails with error:
>> ERROR:  property "name" data type modifier mismatch: 19 vs. 14
>> DETAIL:  In a property graph, a property of the same name has to have
>> the same type modifier in each label.
>> 
>> Labels luser and lgroup both have property "name" originated from 
>> tables
>> userslist and groupslist
>> with types VARCHAR(40) and VARCHAR(30). Current implementation treats
>> them as fields with
>> different types. I think, they should not be treated as different 
>> types.
>> Typmod is additional
>> constrain, it does not create another type.
>> Documentation includes:"modifiers, that is optional constraints 
>> attached
>> to a type declaration,
>> such as char(5) or numeric(30,2)"
>> 
>> Operations with values using different typmod do not require cast, 
>> they
>> treated as the
>> same type.
> 
> When a property is projected in a COLUMNS clause, it will be added to
> the SELECT list of the rewritten query, which in turn could be a UNION
> query. Having the same typmod for all the properties with the same
> name makes it easy to write the SELECT list of UNION. Otherwise, we
> have to find a common typmod for all the properties. This restriction
> is not expected to be permanent but makes the first set of patches
> easy, which are quite large as is. I think in some next version, we
> will lift this restriction as well as lift the restriction on all
> properties with the same name needing the same datatype. According to
> the SQL standard, they can be of different data types as long as
> there's a common type to which they all can be cast to. It may be
> possible to lift this restriction in this version itself, if we find
> enough developer and reviewer bandwidth.
Hi!

  Thank you for explanation. I expected, that it has some internal
dependency, but did not find it.
I am running graph queries now, and I will see how they interact with
typmod.

-- 
Best regards,

Vladlen Popolitov.

  48. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-02-26T14:34:38Z

    On Sun, Feb 23, 2025 at 8:54 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> On Mon, Feb 10, 2025 at 11:00 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > Hi Ashutosh,
> >
> > On Mon, Feb 10, 2025 at 2:14 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > On Thu, Feb 6, 2025 at 8:22 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > > > >
> > > > >
> > > > > I see you have added some negative tests - object not found tests, but
> > > > > I didn't see positive tests. Hence I haven't added those changes in
> > > > > the attached patchset. But we certainly need those changes. You may
> > > > > want to submit a patch with positive tests. That code needs to be
> > > > > fixed before committing anyway.
> > > >
> > > > The attached file adds the positive tests.
> > >
> > > Hi Junwang,
> > > Thanks for the patch, but please post it as a separate patch in the
> > > full patch-set, otherwise CFBot gets confused.
> >
> > Ok, see the attached.
> >
> > 0001-0009 are the original patches of 20250127 with rebase of master
> > 0010 fix ci error due to `Show more-intuitive titles for psql
> > commands`, see a14707da564e
> > 0011 fix ci error due to unstable collation tests, we should not
> > depend on pg_catalog."default", I observed 002_pg_upgrade.pl failure
> > caused by this.
> > 0012 trivial refactor of property graph object address
> >
> > >
> > > --
> > > Best Wishes,
> > > Ashutosh Bapat
> >
> >
> >
> > --
> > Regards
> > Junwang Zhao
>
> Here is v11 with another trivial refactor, I add a seperate patch file 0013, in
> insert_property_record, there is no need to check `type`, `typmode` and
> `collation` if the property doesn't exists before, in AlterPropGraph, there is
> no need to call `check_all_labels_properties` for each added vertex or edge.
>
> Other files remain unchanged except I’ve added some missing document and
> typo fix we discussed in the list but not included in the previous
> patch, I included
> them in 0008.
>
> --
> Regards
> Junwang Zhao

Current patch set failed the cfbot, I did some analysis on this, the reason for
the failure is that backend has a core dump, I extract some queries from
graph_table.sql to reproduce the issue:

----------------- queries begin -----------------
CREATE SCHEMA graph_table_tests;
GRANT USAGE ON SCHEMA graph_table_tests TO PUBLIC;
SET search_path = graph_table_tests;

CREATE TABLE products (
    product_no integer PRIMARY KEY,
    name varchar,
    price numeric
);

CREATE TABLE customers (
    customer_id integer PRIMARY KEY,
    name varchar,
    address varchar
);

CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    ordered_when date
);

CREATE TABLE order_items (
    order_items_id integer PRIMARY KEY,
    order_id integer REFERENCES orders (order_id),
    product_no integer REFERENCES products (product_no),
    quantity integer
);

CREATE TABLE customer_orders (
    customer_orders_id integer PRIMARY KEY,
    customer_id integer REFERENCES customers (customer_id),
    order_id integer REFERENCES orders (order_id)
);


CREATE VIEW customers_view AS SELECT customer_id, 'redacted' ||
customer_id AS name_redacted, address FROM customers;

CREATE PROPERTY GRAPH myshop2
    VERTEX TABLES (
        products,
        customers_view KEY (customer_id) LABEL customers,
        orders
    )
    EDGE TABLES (
        order_items KEY (order_items_id)
            SOURCE KEY (order_id) REFERENCES orders (order_id)
            DESTINATION KEY (product_no) REFERENCES products (product_no),
        customer_orders KEY (customer_orders_id)
            SOURCE KEY (customer_id) REFERENCES customers_view (customer_id)
            DESTINATION KEY (order_id) REFERENCES orders (order_id)
    );

CREATE VIEW customers_us_redacted AS SELECT * FROM GRAPH_TABLE
(myshop2 MATCH (c IS customers WHERE c.address = 'US')-[IS
customer_orders]->(o IS orders) COLUMNS (c.name_redacted AS
customer_name_redacted));

SELECT * FROM customers_us_redacted;         <----- abort on this query
----------------- queries end -----------------

The backend aborted in ExecCheckPermissions, a recent commit 525392d57
add the following check:

----------------- code begin -----------------
/*
* Ensure that we have at least an AccessShareLock on relations
* whose permissions need to be checked.
*
* Skip this check in a parallel worker because locks won't be
* taken until ExecInitNode() performs plan initialization.
*
* XXX: ExecCheckPermissions() in a parallel worker may be
* redundant with the checks done in the leader process, so this
* should be reviewed to ensure it’s necessary.
*/
Assert(IsParallelWorker() ||
CheckRelationOidLockedByMe(rte->relid, AccessShareLock,
true));
----------------- code end -----------------

The query causing the core dump doesn't call transformRangeGraphTable
because the graph table is not in the `from` lists, so the graph table
is not locked.

I added a trivial fix(v12-0014) that called table_open/table_close in
rewriteGraphTable, it now passed the regression test and cirrus ci test,
but I'm not sure it's the correct fix.

I hope Ashutosh can chime in and take a look at this problem.




--
Regards
Junwang Zhao

  49. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-03-11T06:06:41Z

    Hi Amit and Ashutosh,

On Tue, Mar 11, 2025 at 8:19 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Amit,
>
> On Tue, Mar 11, 2025 at 5:06 PM Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > Hi Ashutosh, Junwang,
> >
> > On Tue, Mar 11, 2025 at 4:22 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > > On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > > I added a trivial fix(v12-0014) that called table_open/table_close in
> > > > rewriteGraphTable, it now passed the regression test and cirrus ci test,
> > > > but I'm not sure it's the correct fix.
> > > >
> > > > I hope Ashutosh can chime in and take a look at this problem.
> > >
> > > 2. Following Assertion is failing, the assertion was added recently.
> > > TRAP: failed Assert("IsParallelWorker() ||
> > > CheckRelationOidLockedByMe(rte->relid, AccessShareLock, true)"), File:
> > > "../../coderoot/pg/src/backend/executor/execMain.c", Line: 695, PID:
> > > 303994
> > > postgres: ashutosh regression [local]
> > > SELECT(ExceptionalCondition+0xbe)[0x5c838c5d7114]
> > > postgres: ashutosh regression [local]
> > > SELECT(ExecCheckPermissions+0xf8)[0x5c838c11fb9c]
> > > postgres: ashutosh regression [local] SELECT(+0x38223f)[0x5c838c12023f]
> > > postgres: ashutosh regression [local]
> > > SELECT(standard_ExecutorStart+0x2f8)[0x5c838c11f223]
> > > postgres: ashutosh regression [local] SELECT(ExecutorStart+0x69)[0x5c838c11ef22]
> > > postgres: ashutosh regression [local] SELECT(PortalStart+0x368)[0x5c838c3d991a]
> > > postgres: ashutosh regression [local] SELECT(+0x63458e)[0x5c838c3d258e]
> > > postgres: ashutosh regression [local] SELECT(PostgresMain+0x9eb)[0x5c838c3d7cf0]
> > > postgres: ashutosh regression [local] SELECT(+0x630178)[0x5c838c3ce178]
> > > postgres: ashutosh regression [local]
> > > SELECT(postmaster_child_launch+0x137)[0x5c838c2da677]
> > > postgres: ashutosh regression [local] SELECT(+0x5431b4)[0x5c838c2e11b4]
> > > postgres: ashutosh regression [local] SELECT(+0x54076a)[0x5c838c2de76a]
> > > postgres: ashutosh regression [local]
> > > SELECT(PostmasterMain+0x15f8)[0x5c838c2de04d]
> > > postgres: ashutosh regression [local] SELECT(main+0x3a1)[0x5c838c1b12be]
> > > /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7eda9ea29d90]
> > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7eda9ea29e40]
> > > postgres: ashutosh regression [local] SELECT(_start+0x25)[0x5c838be7c025]
> > > 2025-03-11 11:40:01.696 IST postmaster[303081] LOG: client backend
> > > (PID 303994) was terminated by signal 6: Aborted
> > > 2025-03-11 11:40:01.696 IST postmaster[303081] DETAIL: Failed process
> > > was running: select * from atpgv1;
> > > I tried to investigate the Assertion, it's failing for property graph
> > > RTE which is turned into subquery RTE. It has the right lock mode set,
> > > but I haven't been able to figure out where the lock is supposed to be
> > > taken or where it's released. If we just prepare the failing query and
> > > execute the prepared statement, it does not trip the assertion. Will
> > > investigate it more.
> >
> > I reproduced the crash using the example Junwang gave.
> >
> > The problem seems to be that RTEs of rtekind RTE_GRAPH_TABLE are not
> > handled in AcquireRewriteLocks().  You'll need to add a case for
> > RTE_GRAPH_TABLE similar to RTE_RELATION in the following switch of
> > that function:
> >
> >     /*
> >      * First, process RTEs of the current query level.
> >      */
> >     rt_index = 0;
> >     foreach(l, parsetree->rtable)
> >     {
> >         RangeTblEntry *rte = (RangeTblEntry *) lfirst(l);
> >         Relation    rel;
> >         LOCKMODE    lockmode;
> >         List       *newaliasvars;
> >         Index       curinputvarno;
> >         RangeTblEntry *curinputrte;
> >         ListCell   *ll;
> >
> >         ++rt_index;
> >         switch (rte->rtekind)
> >         {
> >             case RTE_RELATION:
> >
> > which could be as simple as the following (fixes the crash!) or
> > something that's specific to RTE_GRAPH_TABLE:
> >
> > diff --git a/src/backend/rewrite/rewriteHandler.c
> > b/src/backend/rewrite/rewriteHandler.c
> > index c51dd3d2ee4..8fa6edb90eb 100644
> > --- a/src/backend/rewrite/rewriteHandler.c
> > +++ b/src/backend/rewrite/rewriteHandler.c
> > @@ -174,6 +174,7 @@ AcquireRewriteLocks(Query *parsetree,
> >          switch (rte->rtekind)
> >          {
> >              case RTE_RELATION:
> > +            case RTE_GRAPH_TABLE:
> >
> > --
> > Thanks, Amit Langote
>
> I’ve tested the fix, it works and is better than my previous solution.
> I will send a new patch set with this improvement, thanks.
>
> --
> Regards
> Junwang Zhao

Here is a new version with Amit's fix and my trivial refactors.

0001-0010 is the same as Ashutosh's last email
0011 is Amit's fix of the crash in ExecCheckPermissions
0012 is a trivial fix that remove the test with default collation, or
it will fail CI, see[1]
0013-0015 are some trivial fix and refactor, feel free to incorporate
or drop when you review them.

[1]: https://api.cirrus-ci.com/v1/artifact/task/5290818690351104/testrun/build/testrun/regress/regress/regression.diffs

-- 
Regards
Junwang Zhao

  50. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-03-11T07:21:40Z

    Hi Junwang,

On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
.
>
> I added a trivial fix(v12-0014) that called table_open/table_close in
> rewriteGraphTable, it now passed the regression test and cirrus ci test,
> but I'm not sure it's the correct fix.
>
> I hope Ashutosh can chime in and take a look at this problem.

Looks like the first patch has grown some conflicts. Here's set of
rebased patches. There are two main things missing from this patchset

1. Junwang's patches - Extremely sorry, didn't get time to include
your patches. Junwang, you may want to post whole patchset rebased on
attached patch set. I hope to review and incorporate your patches some
time soon.

2. Following Assertion is failing, the assertion was added recently.
TRAP: failed Assert("IsParallelWorker() ||
CheckRelationOidLockedByMe(rte->relid, AccessShareLock, true)"), File:
"../../coderoot/pg/src/backend/executor/execMain.c", Line: 695, PID:
303994
postgres: ashutosh regression [local]
SELECT(ExceptionalCondition+0xbe)[0x5c838c5d7114]
postgres: ashutosh regression [local]
SELECT(ExecCheckPermissions+0xf8)[0x5c838c11fb9c]
postgres: ashutosh regression [local] SELECT(+0x38223f)[0x5c838c12023f]
postgres: ashutosh regression [local]
SELECT(standard_ExecutorStart+0x2f8)[0x5c838c11f223]
postgres: ashutosh regression [local] SELECT(ExecutorStart+0x69)[0x5c838c11ef22]
postgres: ashutosh regression [local] SELECT(PortalStart+0x368)[0x5c838c3d991a]
postgres: ashutosh regression [local] SELECT(+0x63458e)[0x5c838c3d258e]
postgres: ashutosh regression [local] SELECT(PostgresMain+0x9eb)[0x5c838c3d7cf0]
postgres: ashutosh regression [local] SELECT(+0x630178)[0x5c838c3ce178]
postgres: ashutosh regression [local]
SELECT(postmaster_child_launch+0x137)[0x5c838c2da677]
postgres: ashutosh regression [local] SELECT(+0x5431b4)[0x5c838c2e11b4]
postgres: ashutosh regression [local] SELECT(+0x54076a)[0x5c838c2de76a]
postgres: ashutosh regression [local]
SELECT(PostmasterMain+0x15f8)[0x5c838c2de04d]
postgres: ashutosh regression [local] SELECT(main+0x3a1)[0x5c838c1b12be]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7eda9ea29d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7eda9ea29e40]
postgres: ashutosh regression [local] SELECT(_start+0x25)[0x5c838be7c025]
2025-03-11 11:40:01.696 IST postmaster[303081] LOG: client backend
(PID 303994) was terminated by signal 6: Aborted
2025-03-11 11:40:01.696 IST postmaster[303081] DETAIL: Failed process
was running: select * from atpgv1;
I tried to investigate the Assertion, it's failing for property graph
RTE which is turned into subquery RTE. It has the right lock mode set,
but I haven't been able to figure out where the lock is supposed to be
taken or where it's released. If we just prepare the failing query and
execute the prepared statement, it does not trip the assertion. Will
investigate it more.



-- 
Best Wishes,
Ashutosh Bapat

  51. Re: SQL Property Graph Queries (SQL/PGQ)

    amit <amitlangote09@gmail.com> — 2025-03-11T09:06:37Z

    Hi Ashutosh, Junwang,

On Tue, Mar 11, 2025 at 4:22 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > I added a trivial fix(v12-0014) that called table_open/table_close in
> > rewriteGraphTable, it now passed the regression test and cirrus ci test,
> > but I'm not sure it's the correct fix.
> >
> > I hope Ashutosh can chime in and take a look at this problem.
>
> 2. Following Assertion is failing, the assertion was added recently.
> TRAP: failed Assert("IsParallelWorker() ||
> CheckRelationOidLockedByMe(rte->relid, AccessShareLock, true)"), File:
> "../../coderoot/pg/src/backend/executor/execMain.c", Line: 695, PID:
> 303994
> postgres: ashutosh regression [local]
> SELECT(ExceptionalCondition+0xbe)[0x5c838c5d7114]
> postgres: ashutosh regression [local]
> SELECT(ExecCheckPermissions+0xf8)[0x5c838c11fb9c]
> postgres: ashutosh regression [local] SELECT(+0x38223f)[0x5c838c12023f]
> postgres: ashutosh regression [local]
> SELECT(standard_ExecutorStart+0x2f8)[0x5c838c11f223]
> postgres: ashutosh regression [local] SELECT(ExecutorStart+0x69)[0x5c838c11ef22]
> postgres: ashutosh regression [local] SELECT(PortalStart+0x368)[0x5c838c3d991a]
> postgres: ashutosh regression [local] SELECT(+0x63458e)[0x5c838c3d258e]
> postgres: ashutosh regression [local] SELECT(PostgresMain+0x9eb)[0x5c838c3d7cf0]
> postgres: ashutosh regression [local] SELECT(+0x630178)[0x5c838c3ce178]
> postgres: ashutosh regression [local]
> SELECT(postmaster_child_launch+0x137)[0x5c838c2da677]
> postgres: ashutosh regression [local] SELECT(+0x5431b4)[0x5c838c2e11b4]
> postgres: ashutosh regression [local] SELECT(+0x54076a)[0x5c838c2de76a]
> postgres: ashutosh regression [local]
> SELECT(PostmasterMain+0x15f8)[0x5c838c2de04d]
> postgres: ashutosh regression [local] SELECT(main+0x3a1)[0x5c838c1b12be]
> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7eda9ea29d90]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7eda9ea29e40]
> postgres: ashutosh regression [local] SELECT(_start+0x25)[0x5c838be7c025]
> 2025-03-11 11:40:01.696 IST postmaster[303081] LOG: client backend
> (PID 303994) was terminated by signal 6: Aborted
> 2025-03-11 11:40:01.696 IST postmaster[303081] DETAIL: Failed process
> was running: select * from atpgv1;
> I tried to investigate the Assertion, it's failing for property graph
> RTE which is turned into subquery RTE. It has the right lock mode set,
> but I haven't been able to figure out where the lock is supposed to be
> taken or where it's released. If we just prepare the failing query and
> execute the prepared statement, it does not trip the assertion. Will
> investigate it more.

I reproduced the crash using the example Junwang gave.

The problem seems to be that RTEs of rtekind RTE_GRAPH_TABLE are not
handled in AcquireRewriteLocks().  You'll need to add a case for
RTE_GRAPH_TABLE similar to RTE_RELATION in the following switch of
that function:

    /*
     * First, process RTEs of the current query level.
     */
    rt_index = 0;
    foreach(l, parsetree->rtable)
    {
        RangeTblEntry *rte = (RangeTblEntry *) lfirst(l);
        Relation    rel;
        LOCKMODE    lockmode;
        List       *newaliasvars;
        Index       curinputvarno;
        RangeTblEntry *curinputrte;
        ListCell   *ll;

        ++rt_index;
        switch (rte->rtekind)
        {
            case RTE_RELATION:

which could be as simple as the following (fixes the crash!) or
something that's specific to RTE_GRAPH_TABLE:

diff --git a/src/backend/rewrite/rewriteHandler.c
b/src/backend/rewrite/rewriteHandler.c
index c51dd3d2ee4..8fa6edb90eb 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite/rewriteHandler.c
@@ -174,6 +174,7 @@ AcquireRewriteLocks(Query *parsetree,
         switch (rte->rtekind)
         {
             case RTE_RELATION:
+            case RTE_GRAPH_TABLE:

-- 
Thanks, Amit Langote

  52. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-03-11T12:19:25Z

    Hi Amit,

On Tue, Mar 11, 2025 at 5:06 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> Hi Ashutosh, Junwang,
>
> On Tue, Mar 11, 2025 at 4:22 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> > On Wed, Feb 26, 2025 at 8:04 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > I added a trivial fix(v12-0014) that called table_open/table_close in
> > > rewriteGraphTable, it now passed the regression test and cirrus ci test,
> > > but I'm not sure it's the correct fix.
> > >
> > > I hope Ashutosh can chime in and take a look at this problem.
> >
> > 2. Following Assertion is failing, the assertion was added recently.
> > TRAP: failed Assert("IsParallelWorker() ||
> > CheckRelationOidLockedByMe(rte->relid, AccessShareLock, true)"), File:
> > "../../coderoot/pg/src/backend/executor/execMain.c", Line: 695, PID:
> > 303994
> > postgres: ashutosh regression [local]
> > SELECT(ExceptionalCondition+0xbe)[0x5c838c5d7114]
> > postgres: ashutosh regression [local]
> > SELECT(ExecCheckPermissions+0xf8)[0x5c838c11fb9c]
> > postgres: ashutosh regression [local] SELECT(+0x38223f)[0x5c838c12023f]
> > postgres: ashutosh regression [local]
> > SELECT(standard_ExecutorStart+0x2f8)[0x5c838c11f223]
> > postgres: ashutosh regression [local] SELECT(ExecutorStart+0x69)[0x5c838c11ef22]
> > postgres: ashutosh regression [local] SELECT(PortalStart+0x368)[0x5c838c3d991a]
> > postgres: ashutosh regression [local] SELECT(+0x63458e)[0x5c838c3d258e]
> > postgres: ashutosh regression [local] SELECT(PostgresMain+0x9eb)[0x5c838c3d7cf0]
> > postgres: ashutosh regression [local] SELECT(+0x630178)[0x5c838c3ce178]
> > postgres: ashutosh regression [local]
> > SELECT(postmaster_child_launch+0x137)[0x5c838c2da677]
> > postgres: ashutosh regression [local] SELECT(+0x5431b4)[0x5c838c2e11b4]
> > postgres: ashutosh regression [local] SELECT(+0x54076a)[0x5c838c2de76a]
> > postgres: ashutosh regression [local]
> > SELECT(PostmasterMain+0x15f8)[0x5c838c2de04d]
> > postgres: ashutosh regression [local] SELECT(main+0x3a1)[0x5c838c1b12be]
> > /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7eda9ea29d90]
> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7eda9ea29e40]
> > postgres: ashutosh regression [local] SELECT(_start+0x25)[0x5c838be7c025]
> > 2025-03-11 11:40:01.696 IST postmaster[303081] LOG: client backend
> > (PID 303994) was terminated by signal 6: Aborted
> > 2025-03-11 11:40:01.696 IST postmaster[303081] DETAIL: Failed process
> > was running: select * from atpgv1;
> > I tried to investigate the Assertion, it's failing for property graph
> > RTE which is turned into subquery RTE. It has the right lock mode set,
> > but I haven't been able to figure out where the lock is supposed to be
> > taken or where it's released. If we just prepare the failing query and
> > execute the prepared statement, it does not trip the assertion. Will
> > investigate it more.
>
> I reproduced the crash using the example Junwang gave.
>
> The problem seems to be that RTEs of rtekind RTE_GRAPH_TABLE are not
> handled in AcquireRewriteLocks().  You'll need to add a case for
> RTE_GRAPH_TABLE similar to RTE_RELATION in the following switch of
> that function:
>
>     /*
>      * First, process RTEs of the current query level.
>      */
>     rt_index = 0;
>     foreach(l, parsetree->rtable)
>     {
>         RangeTblEntry *rte = (RangeTblEntry *) lfirst(l);
>         Relation    rel;
>         LOCKMODE    lockmode;
>         List       *newaliasvars;
>         Index       curinputvarno;
>         RangeTblEntry *curinputrte;
>         ListCell   *ll;
>
>         ++rt_index;
>         switch (rte->rtekind)
>         {
>             case RTE_RELATION:
>
> which could be as simple as the following (fixes the crash!) or
> something that's specific to RTE_GRAPH_TABLE:
>
> diff --git a/src/backend/rewrite/rewriteHandler.c
> b/src/backend/rewrite/rewriteHandler.c
> index c51dd3d2ee4..8fa6edb90eb 100644
> --- a/src/backend/rewrite/rewriteHandler.c
> +++ b/src/backend/rewrite/rewriteHandler.c
> @@ -174,6 +174,7 @@ AcquireRewriteLocks(Query *parsetree,
>          switch (rte->rtekind)
>          {
>              case RTE_RELATION:
> +            case RTE_GRAPH_TABLE:
>
> --
> Thanks, Amit Langote

I’ve tested the fix, it works and is better than my previous solution.
I will send a new patch set with this improvement, thanks.

-- 
Regards
Junwang Zhao

  53. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-03-12T04:31:38Z

    Thanks

On Tue, Mar 11, 2025 at 7:51 PM Junwang Zhao <zhjwpku@gmail.com> wrote:

>
> Here is a new version with Amit's fix and my trivial refactors.
>
> 0001-0010 is the same as Ashutosh's last email
> 0011 is Amit's fix of the crash in ExecCheckPermissions

I think that fix is correct and it fixes the crash. I need to think
more about it - especially whether there are more places where we are
missing RTE_GRAPH_TABLE. But will do that as time permits.

> 0012 is a trivial fix that remove the test with default collation, or
> it will fail CI, see[1]
> 0013-0015 are some trivial fix and refactor, feel free to incorporate
> or drop when you review them.
>
> [1]: https://api.cirrus-ci.com/v1/artifact/task/5290818690351104/testrun/build/testrun/regress/regress/regression.diffs
>

Thanks Junwang. I have added your patches to my local repository. Next
time I post an updated set, I will post it along with your patches.
Will merge them into the original patches as time permits.

-- 
Best Wishes,
Ashutosh Bapat

  54. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-04-05T12:50:34Z

    Hi Ashutosh and Peter,

On Wed, Mar 12, 2025 at 12:31 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Thanks
>
> On Tue, Mar 11, 2025 at 7:51 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> >
> > Here is a new version with Amit's fix and my trivial refactors.
> >
> > 0001-0010 is the same as Ashutosh's last email
> > 0011 is Amit's fix of the crash in ExecCheckPermissions
>
> I think that fix is correct and it fixes the crash. I need to think
> more about it - especially whether there are more places where we are
> missing RTE_GRAPH_TABLE. But will do that as time permits.
>
> > 0012 is a trivial fix that remove the test with default collation, or
> > it will fail CI, see[1]
> > 0013-0015 are some trivial fix and refactor, feel free to incorporate
> > or drop when you review them.
> >
> > [1]: https://api.cirrus-ci.com/v1/artifact/task/5290818690351104/testrun/build/testrun/regress/regress/regression.diffs
> >
>
> Thanks Junwang. I have added your patches to my local repository. Next
> time I post an updated set, I will post it along with your patches.
> Will merge them into the original patches as time permits.
>
> --
> Best Wishes,
> Ashutosh Bapat

Since this PGQ feature won't be in PG 18, I'd like to raise a discussion of
the possibility of implementing the quantifier feature, which I think is a
quite useful feature in the graph database area.

I'll start with a graph definition first.

`Person(id, name, age, sex)` with id as PK
`Knows(id, start_id, end_id, since)` with id as PK, start_id and
end_id FK referencing Person's id

insert into Person values(1, 'A', 31, 'M'), (2, 'B', 30, 'F'), (3,
'C', 33, 'M'), (4, 'D', 31, 'F'), (5, 'E', 32, 'M'), (6, 'F', 33,
'M');
insert into Knows values (1, 1, 2, '2020');  -- A knows B since 2020
insert into Knows values (2, 1, 3, '2021');  -- A knows C since 2021
insert into Knows values (3, 1, 4, '2020');  -- A knows D since 2020
insert into Knows values (4, 2, 4, '2023');  -- B knows D since 2023
insert into Knows values (5, 3, 5, '2022');  -- C knows E since 2022
insert into Knows values (6, 2, 6, '2021');  -- B knows F since 2021
insert into Knows values (7, 4, 6, '2020');  -- D knows F since 2020

Then we create a property graph:

CREATE property graph new_graph
VERTEX TABLES (Person)
EDGE TABLES (Knows);

If we want to find A's non-directly known friends within 3 hops, we can query:

select name from graph_table (new_graph match (a:Person WHERE a.name =
'A') --> (b:Person) --> (c:Person) COLUMNS (c.name))
union
select name from graph_table (new_graph match (a:Person WHERE a.name =
'A') --> (b:Person) -->(c:Person)-->(d:Person) COLUMNS (d.name));

Or if we support quantifier, we can simply the query as:

select name from graph_table (new_graph match (a:Person WHERE a.name =
'A') -->{2,3} (b:Person) COLUMNS (b.name));

In the current design of PostgreSQL, we can rewrite this pattern with
quantifiers to
the union form with some effort.

But what if the pattern is more complicated, for example:

1. select name, since from graph_table (new_graph match (a:Person
WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
r.since));
Can we support the r.since column? I guess not, in this case r is a
variable length edge.

2. select name, count from graph_table (new_graph match (a:Person
WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
count(r)));
Can we support this count aggregation(this is called horizontal
aggregation in Oracle's pgql)? How can the executor know the length of
the variable length edge?

3. What if the query doesn't specify the Label of edge, and there can
be different edge labels of r, can we easily do the rewrite?

I did some study of the apache age, they have fixed columns for node
labels(id, agtype)
and edge labels(id, source_id, end_id, agtype), agtype is kind of
json. So they can
resolve the above question easily.

Above are just my random thoughts of the quantifier feature, I don't have a copy
of the PGQ standard, so I'd like to hear your opinion about this.

[1] https://pgql-lang.org/spec/1.2/#horizontal-aggregation-using-group-variables

-- 
Regards
Junwang Zhao

  55. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-04-07T05:19:40Z

    On Sat, Apr 5, 2025 at 6:20 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Ashutosh and Peter,
>
> Since this PGQ feature won't be in PG 18, I'd like to raise a discussion of
> the possibility of implementing the quantifier feature, which I think is a
> quite useful feature in the graph database area.

I agree that quantifiers feature is very useful; it's being used in
many usecases. However, it's a bit of a complex feature. IMO, we
should keep that discussion as well as the patch in a separate thread,
so that this patchset doesn't grow too large to review and also
discussion in this thread can remain focused. Once we get the current
patch set reviewed and committed we can tackle the quantifier problem
in a separate discussion. Of course that doesn't mean that we can not
start discussion, try POC and even a working patch for quantifier
support.

Peter may think otherwise.

>
> I'll start with a graph definition first.
>
> `Person(id, name, age, sex)` with id as PK
> `Knows(id, start_id, end_id, since)` with id as PK, start_id and
> end_id FK referencing Person's id
>
> insert into Person values(1, 'A', 31, 'M'), (2, 'B', 30, 'F'), (3,
> 'C', 33, 'M'), (4, 'D', 31, 'F'), (5, 'E', 32, 'M'), (6, 'F', 33,
> 'M');
> insert into Knows values (1, 1, 2, '2020');  -- A knows B since 2020
> insert into Knows values (2, 1, 3, '2021');  -- A knows C since 2021
> insert into Knows values (3, 1, 4, '2020');  -- A knows D since 2020
> insert into Knows values (4, 2, 4, '2023');  -- B knows D since 2023
> insert into Knows values (5, 3, 5, '2022');  -- C knows E since 2022
> insert into Knows values (6, 2, 6, '2021');  -- B knows F since 2021
> insert into Knows values (7, 4, 6, '2020');  -- D knows F since 2020
>
> Then we create a property graph:
>
> CREATE property graph new_graph
> VERTEX TABLES (Person)
> EDGE TABLES (Knows);
>
> If we want to find A's non-directly known friends within 3 hops, we can query:
>
> select name from graph_table (new_graph match (a:Person WHERE a.name =
> 'A') --> (b:Person) --> (c:Person) COLUMNS (c.name))
> union
> select name from graph_table (new_graph match (a:Person WHERE a.name =
> 'A') --> (b:Person) -->(c:Person)-->(d:Person) COLUMNS (d.name));
>
> Or if we support quantifier, we can simply the query as:
>
> select name from graph_table (new_graph match (a:Person WHERE a.name =
> 'A') -->{2,3} (b:Person) COLUMNS (b.name));
>
> In the current design of PostgreSQL, we can rewrite this pattern with
> quantifiers to
> the union form with some effort.
>
> But what if the pattern is more complicated, for example:
>
> 1. select name, since from graph_table (new_graph match (a:Person
> WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> r.since));
> Can we support the r.since column? I guess not, in this case r is a
> variable length edge.
>
> 2. select name, count from graph_table (new_graph match (a:Person
> WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> count(r)));
> Can we support this count aggregation(this is called horizontal
> aggregation in Oracle's pgql)? How can the executor know the length of
> the variable length edge?
>
> 3. What if the query doesn't specify the Label of edge, and there can
> be different edge labels of r, can we easily do the rewrite?
>
> I did some study of the apache age, they have fixed columns for node
> labels(id, agtype)
> and edge labels(id, source_id, end_id, agtype), agtype is kind of
> json. So they can
> resolve the above question easily.
>
> Above are just my random thoughts of the quantifier feature, I don't have a copy
> of the PGQ standard, so I'd like to hear your opinion about this.
>

I think the questions you have raised are valid. If we decide to
discuss this in a separate thread, I will start that thread just by
responding to these questions and design I have in mind.

-- 
Best Wishes,
Ashutosh Bapat

  56. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-04-07T08:13:35Z

    Hi Ashutosh,

On Mon, Apr 7, 2025 at 1:19 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Sat, Apr 5, 2025 at 6:20 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > Hi Ashutosh and Peter,
> >
> > Since this PGQ feature won't be in PG 18, I'd like to raise a discussion of
> > the possibility of implementing the quantifier feature, which I think is a
> > quite useful feature in the graph database area.
>
> I agree that quantifiers feature is very useful; it's being used in
> many usecases. However, it's a bit of a complex feature. IMO, we
> should keep that discussion as well as the patch in a separate thread,
> so that this patchset doesn't grow too large to review and also
> discussion in this thread can remain focused. Once we get the current
> patch set reviewed and committed we can tackle the quantifier problem
> in a separate discussion. Of course that doesn't mean that we can not
> start discussion, try POC and even a working patch for quantifier
> support.
>
> Peter may think otherwise.
>
> >
> > I'll start with a graph definition first.
> >
> > `Person(id, name, age, sex)` with id as PK
> > `Knows(id, start_id, end_id, since)` with id as PK, start_id and
> > end_id FK referencing Person's id
> >
> > insert into Person values(1, 'A', 31, 'M'), (2, 'B', 30, 'F'), (3,
> > 'C', 33, 'M'), (4, 'D', 31, 'F'), (5, 'E', 32, 'M'), (6, 'F', 33,
> > 'M');
> > insert into Knows values (1, 1, 2, '2020');  -- A knows B since 2020
> > insert into Knows values (2, 1, 3, '2021');  -- A knows C since 2021
> > insert into Knows values (3, 1, 4, '2020');  -- A knows D since 2020
> > insert into Knows values (4, 2, 4, '2023');  -- B knows D since 2023
> > insert into Knows values (5, 3, 5, '2022');  -- C knows E since 2022
> > insert into Knows values (6, 2, 6, '2021');  -- B knows F since 2021
> > insert into Knows values (7, 4, 6, '2020');  -- D knows F since 2020
> >
> > Then we create a property graph:
> >
> > CREATE property graph new_graph
> > VERTEX TABLES (Person)
> > EDGE TABLES (Knows);
> >
> > If we want to find A's non-directly known friends within 3 hops, we can query:
> >
> > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > 'A') --> (b:Person) --> (c:Person) COLUMNS (c.name))
> > union
> > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > 'A') --> (b:Person) -->(c:Person)-->(d:Person) COLUMNS (d.name));
> >
> > Or if we support quantifier, we can simply the query as:
> >
> > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > 'A') -->{2,3} (b:Person) COLUMNS (b.name));
> >
> > In the current design of PostgreSQL, we can rewrite this pattern with
> > quantifiers to
> > the union form with some effort.
> >
> > But what if the pattern is more complicated, for example:
> >
> > 1. select name, since from graph_table (new_graph match (a:Person
> > WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> > r.since));
> > Can we support the r.since column? I guess not, in this case r is a
> > variable length edge.
> >
> > 2. select name, count from graph_table (new_graph match (a:Person
> > WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> > count(r)));
> > Can we support this count aggregation(this is called horizontal
> > aggregation in Oracle's pgql)? How can the executor know the length of
> > the variable length edge?
> >
> > 3. What if the query doesn't specify the Label of edge, and there can
> > be different edge labels of r, can we easily do the rewrite?
> >
> > I did some study of the apache age, they have fixed columns for node
> > labels(id, agtype)
> > and edge labels(id, source_id, end_id, agtype), agtype is kind of
> > json. So they can
> > resolve the above question easily.
> >
> > Above are just my random thoughts of the quantifier feature, I don't have a copy
> > of the PGQ standard, so I'd like to hear your opinion about this.
> >
>
> I think the questions you have raised are valid. If we decide to
> discuss this in a separate thread, I will start that thread just by
> responding to these questions and design I have in mind.

I'm ok with starting a new thread for quantifier discussion, and I'd
really happy to know your design on this.

>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  57. Re: SQL Property Graph Queries (SQL/PGQ)

    Hannu Krosing <hannuk@google.com> — 2025-07-06T16:10:47Z

     What is the current thinking about getting PGQ committed ?

The attached fixes *ONLY* the duplicate OIDs error to get it build again in CI

On Mon, Apr 7, 2025 at 10:13 AM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Ashutosh,
>
> On Mon, Apr 7, 2025 at 1:19 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Sat, Apr 5, 2025 at 6:20 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > >
> > > Hi Ashutosh and Peter,
> > >
> > > Since this PGQ feature won't be in PG 18, I'd like to raise a discussion of
> > > the possibility of implementing the quantifier feature, which I think is a
> > > quite useful feature in the graph database area.
> >
> > I agree that quantifiers feature is very useful; it's being used in
> > many usecases. However, it's a bit of a complex feature. IMO, we
> > should keep that discussion as well as the patch in a separate thread,
> > so that this patchset doesn't grow too large to review and also
> > discussion in this thread can remain focused. Once we get the current
> > patch set reviewed and committed we can tackle the quantifier problem
> > in a separate discussion. Of course that doesn't mean that we can not
> > start discussion, try POC and even a working patch for quantifier
> > support.
> >
> > Peter may think otherwise.
> >
> > >
> > > I'll start with a graph definition first.
> > >
> > > `Person(id, name, age, sex)` with id as PK
> > > `Knows(id, start_id, end_id, since)` with id as PK, start_id and
> > > end_id FK referencing Person's id
> > >
> > > insert into Person values(1, 'A', 31, 'M'), (2, 'B', 30, 'F'), (3,
> > > 'C', 33, 'M'), (4, 'D', 31, 'F'), (5, 'E', 32, 'M'), (6, 'F', 33,
> > > 'M');
> > > insert into Knows values (1, 1, 2, '2020');  -- A knows B since 2020
> > > insert into Knows values (2, 1, 3, '2021');  -- A knows C since 2021
> > > insert into Knows values (3, 1, 4, '2020');  -- A knows D since 2020
> > > insert into Knows values (4, 2, 4, '2023');  -- B knows D since 2023
> > > insert into Knows values (5, 3, 5, '2022');  -- C knows E since 2022
> > > insert into Knows values (6, 2, 6, '2021');  -- B knows F since 2021
> > > insert into Knows values (7, 4, 6, '2020');  -- D knows F since 2020
> > >
> > > Then we create a property graph:
> > >
> > > CREATE property graph new_graph
> > > VERTEX TABLES (Person)
> > > EDGE TABLES (Knows);
> > >
> > > If we want to find A's non-directly known friends within 3 hops, we can query:
> > >
> > > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > > 'A') --> (b:Person) --> (c:Person) COLUMNS (c.name))
> > > union
> > > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > > 'A') --> (b:Person) -->(c:Person)-->(d:Person) COLUMNS (d.name));
> > >
> > > Or if we support quantifier, we can simply the query as:
> > >
> > > select name from graph_table (new_graph match (a:Person WHERE a.name =
> > > 'A') -->{2,3} (b:Person) COLUMNS (b.name));
> > >
> > > In the current design of PostgreSQL, we can rewrite this pattern with
> > > quantifiers to
> > > the union form with some effort.
> > >
> > > But what if the pattern is more complicated, for example:
> > >
> > > 1. select name, since from graph_table (new_graph match (a:Person
> > > WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> > > r.since));
> > > Can we support the r.since column? I guess not, in this case r is a
> > > variable length edge.
> > >
> > > 2. select name, count from graph_table (new_graph match (a:Person
> > > WHERE a.name = 'A') -[r:Knows]->{2,3} (b:Person) COLUMNS (b.name,
> > > count(r)));
> > > Can we support this count aggregation(this is called horizontal
> > > aggregation in Oracle's pgql)? How can the executor know the length of
> > > the variable length edge?
> > >
> > > 3. What if the query doesn't specify the Label of edge, and there can
> > > be different edge labels of r, can we easily do the rewrite?
> > >
> > > I did some study of the apache age, they have fixed columns for node
> > > labels(id, agtype)
> > > and edge labels(id, source_id, end_id, agtype), agtype is kind of
> > > json. So they can
> > > resolve the above question easily.
> > >
> > > Above are just my random thoughts of the quantifier feature, I don't have a copy
> > > of the PGQ standard, so I'd like to hear your opinion about this.
> > >
> >
> > I think the questions you have raised are valid. If we decide to
> > discuss this in a separate thread, I will start that thread just by
> > responding to these questions and design I have in mind.
>
> I'm ok with starting a new thread for quantifier discussion, and I'd
> really happy to know your design on this.
>
> >
> > --
> > Best Wishes,
> > Ashutosh Bapat
>
>
>
> --
> Regards
> Junwang Zhao
>
>

  58. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-07-22T11:40:26Z

    On Wed, Mar 12, 2025 at 10:01 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> >
>
> Thanks Junwang. I have added your patches to my local repository. Next
> time I post an updated set, I will post it along with your patches.
> Will merge them into the original patches as time permits.

I have reviewed your patches. adjusted them as described below.

0001 - is original patch by Peter but it has now accumulated a lot of
conflict resolution fixes, compilation fixes and bug fixes. The commit
message has a list of all the fixes.

0002 - WHERE clause support in graph pattern

0003 - supports cyclic path patterns

0004 - contains a variety of fixes, described in the commit message

0005 - Fixes access permission checks on property graph

0006 - support collation specification for property and handles
collation of vertex - edge quals, this includes Junwang's 0012 and
some part of his 0015. The edit related to reducing number of call
sites didn't look like a net improvement. Having two callsites each
surrounded by the caller's context is better than one.

0007 - pg_overexplain support for property graph (description of
GRAPH_TABLE RTE)

0008 - documentation fixes

0009 - support \d variants for property graph, includes Junwang's 0013

0010 - handles RTE_GRAPH_TABLE at some more places. This includes
Amit's fix for crash in ExecCheckPermissions.

0011 - deals with functions related to object addresses. It's clear
what should be the output of pg_describe_object(),
pg_identify_object() and pg_identify_object_as_address() for property
graph elements, property graph labels and property graph properties.
Those changes are included in the patch. But in order to support those
objects in pg_get_object_address() we need to add ObjectTypes
corresponding to those objects. Every object that is supported by
pg_describe_object(), pg_identify_object() and
pg_identify_object_as_address() is not supported by
pg_get_object_address(). The objects which are not supported do not
have their object types defined in the ObjectTypes enum. E.g. "index
column" or "view column" etc. So I have not implemented that support
for now. If required, we will need to add the corresponding types in
ObjectTypes and then handle them in all the places where ObjectType
enum is used. This contains Junwang's 0014.

0012 - A change to in the properties of labels or expression
associated with an element property requires the cached plans for
queries referring to the corresponding property graph. For that
CacheInvalidateHeapTupleCommon() needs to lookup OID of property graph
given a Form_pg_propgraph_label_property or
Form_pg_propgraph_element_label tuple. These catalogs do not store the
property graph OID directly. Instead they store label or property or
element oid. From those OIDs it is possible to get the property graph
ID from the corresponding label or property or element tuples.
However, when tuples in those catalogs are added along with the label,
element or property tuples, the latter are not visible. So either we
have to add property graph id to pg_propgraph_label_property and
pg_propgraph_element_label catalogs or add a CommandCounterIncrement()
after inserting element, property or label tuples. The latter may
cause some unwanted changes to be visible other than the desired ones,
so seems risky. Hence going with the first option. However, that
option consumes more space in the catalog. Once the catalog changes
are visible, the property graph id in the tuple won't be useful while
consuming space.

0013 and 0014 - minimum RLS related tests. In previous patchsets this
patch was too large and probably not all tests in that patch were
necessary. Now it's broken into two patches  .0013 which has extra
tests for the combinations. 0014 which I think are tested indirectly
in our regression suite. We may include some of those tests in the
main patchset.

I think two more changes are necessary but not included in the patchset
1. graph_table.sql uses mixed cases in SQL queries (e.g. it uses both
SELECT and select). I think we should use a uniform.
2. We have enhanced 002_pg_upgrade.pl to test dump and restore using
regression database. I think we should use that facility instead of
property graph specific dump/restore tests.

Here's the patchset rebased on the latest master.
-- 
Best Wishes,
Ashutosh Bapat

  59. Re: SQL Property Graph Queries (SQL/PGQ)

    amit <amitlangote09@gmail.com> — 2025-07-23T08:38:36Z

    Hi Ashutosh,

On Tue, Jul 22, 2025 at 8:40 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> Here's the patchset rebased on the latest master.

Thanks for the update. I was going through the patch series today and
had a few comments on the structure that might help with reviewing and
eventually committing, whoever ends up doing that. :)

I noticed that some functions, like graph_table_property_reference(),
are introduced in one patch and then renamed or removed in a later
one. It’s easier to review if such refactoring is avoided across
patches -- ideally, each patch should introduce code in its final
intended form. That also helps reduce the number of patches and makes
each one more self-contained.

One of the later patches (0004) collects several follow-up changes.
While it fixes a real bug -- a crash when GRAPH_TABLE is used inside
plpgsql due to a conflict with the columnref hook -- it also includes
incidental cleanups like switching to foreach_node(), updating
comments, and adjusting function signatures. Those would be better
folded into the patches that introduced the relevant code, rather than
grouped into a catch-all at the end. That keeps each patch focused and
easier to review -- and easier to merge when committing.

A general principle that might help: if you're refactoring existing
code, a standalone preliminary patch makes sense. But if you're
tweaking something just added in the same series, it’s usually better
to squash that into the original patch. The rename from
graph_table_property_reference() to transformGraphTablePropertyRef()
may be a fair exception since it reflects a shift prompted by the bug
fix -- but most other adjustments could be folded in without loss of
clarity.

I understand the intent to spell out each change, but if the details
are incidental to the overall design, they don’t necessarily need to
be split out. Explaining the reasoning in the thread is always
helpful, but consolidating the patches once the design has settled
makes things easier for both reviewers and committers.

Finally, attaching the patches directly, with versioned names like
v8-000x, instead of zipping them helps.  Many folks (myself included)
will casually skip a zip file because of the small hassle of unzipping
just to read a patch. I once postponed reading such a patch and didn’t
get back to it for quite a while. :)

-- 
Thanks, Amit Langote

  60. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-07-29T05:03:46Z

    Hi Andreas,

On Sun, Dec 22, 2024 at 3:15 AM Andreas Karlsson <andreas@proxel.se> wrote:
>
> On 10/29/24 8:55 PM, Andreas Karlsson wrote:
> > I especially dislike the static variable in our patch. And as far as I
> > understand it you can avoid the static by changing the lexer to use the
> > push parser so it can emit multiple terminal tokens from one parsed
> > token, but I have not looked into push parsers and have no idea how this
> > would affect performance.
>
> Updated the patch to remove the static variable. No clue why I thought
> that one was necessary.

I have not included this patch in the latest patchset. Given that
Peter E has written the grammar, it best be handled by him. Please
feel free to post it again as an additional patch in the latest
patchset. A standalone patch like this confused CI Bot.

-- 
Best Wishes,
Ashutosh Bapat

  61. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-08-07T10:47:37Z

    Hi Amit,
Thanks for your comments

On Wed, Jul 23, 2025 at 2:08 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> Hi Ashutosh,
>
> On Tue, Jul 22, 2025 at 8:40 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> > Here's the patchset rebased on the latest master.
>
> Thanks for the update. I was going through the patch series today and
> had a few comments on the structure that might help with reviewing and
> eventually committing, whoever ends up doing that. :)
>
> I noticed that some functions, like graph_table_property_reference(),
> are introduced in one patch and then renamed or removed in a later
> one. It’s easier to review if such refactoring is avoided across
> patches -- ideally, each patch should introduce code in its final
> intended form. That also helps reduce the number of patches and makes
> each one more self-contained.
>
> One of the later patches (0004) collects several follow-up changes.
> While it fixes a real bug -- a crash when GRAPH_TABLE is used inside
> plpgsql due to a conflict with the columnref hook -- it also includes
> incidental cleanups like switching to foreach_node(), updating
> comments, and adjusting function signatures. Those would be better
> folded into the patches that introduced the relevant code, rather than
> grouped into a catch-all at the end. That keeps each patch focused and
> easier to review -- and easier to merge when committing.
>
> A general principle that might help: if you're refactoring existing
> code, a standalone preliminary patch makes sense. But if you're
> tweaking something just added in the same series, it’s usually better
> to squash that into the original patch. The rename from
> graph_table_property_reference() to transformGraphTablePropertyRef()
> may be a fair exception since it reflects a shift prompted by the bug
> fix -- but most other adjustments could be folded in without loss of
> clarity.
>
> I understand the intent to spell out each change, but if the details
> are incidental to the overall design, they don’t necessarily need to
> be split out. Explaining the reasoning in the thread is always
> helpful, but consolidating the patches once the design has settled
> makes things easier for both reviewers and committers.

0001 is almost the same patch that Peter posted almost a year ago.
Each of 0002 onwards patches contains logically grouped changes. I
have changed 0001 minimally (so that it continues to apply, compile
and pass regression). I think this arrangement will make it easy for
Peter to review the changes. It will help him understand what all
changed since 0001 and each change in its own context. That has led to
a lot of overlap between 0002 and 0001 which I think should be
squashed together even now. But I would like to know what Peter thinks
- what would make his review easier. This arrangement might also help
Junwang, who has reviewed some patches, to continue his incremental
review.

I have rearranged the patches 0002 to 0014 so that the same change
isn't revised in multiple patches. Hope that helps.

I am also attaching a single patch as well to this email, so that
newer reviewers can review the changes as a whole.

SQL_PGQ_20250807.zip is separate patches zipped together.
SQL_PGQ_one_patch_20250807.zip is a single diff with changes from all
the patches squashed together. It's still zipped to avoid the email
being held for moderation.

>
> Finally, attaching the patches directly, with versioned names like
> v8-000x, instead of zipping them helps.  Many folks (myself included)
> will casually skip a zip file because of the small hassle of unzipping
> just to read a patch. I once postponed reading such a patch and didn’t
> get back to it for quite a while. :)

I used to attach those as separate patches till [1], but after that
the total size of the patchset grew so much that my emails used to get
held back for moderation. So I started attaching zip files. The
increase in size is mostly due to the 0014 patch. If we think that
it's not needed or can be trimmed down, we will be able to attach the
patchset as separate attachments.

Here's what changed between the last patchset and this

0001 has some TODOs, FIXMEs and XXXs. I and Junwang had fixed some of
them earlier. This patchset fixes some more. Below is my analysis of
each of them.
+
+ <!-- TODO: multiple path patterns in a graph pattern (comma-separated) -->
+
+ <!-- TODO: quantifiers -->

I think we should remove these TODOs since we are not going to support
these cases in this patchset. We will add the documentation when we
implement these features.

+/*
+ * 15.2
+ * PG_DEFINED_LABEL_SETS view
+ */
+
+-- TODO
+
+
+/*
+ * 15.3
+ * PG_DEFINED_LABEL_SET_LABELS view
+ */
+
+-- TODO
+
+
+/*
+ * 15.4
+ * PG_EDGE_DEFINED_LABEL_SETS view
+ */
+
+-- TODO
+
+/*
+ * 15.6
+ * PG_EDGE_TRIPLETS view
+ */
+
+-- TODO
+
+/*
+ * 15.15
+ * PG_VERTEX_DEFINED_LABEL_SETS view
+ */
+
+-- TODO

All these views are related to the defined label set. IIUC, defined
label set is a set of labels which is shared by multiple edges or
vertices of a property graph. Please note it's the whole set shared;
not just individual labels in the set. In that sense, I think, the
labels associated with each edge or vertex table in a property graph
form a defined label set. That way the property graph element's OID
becomes the defined label set's identifier. I am not sure if this view
has any practical use for tabular property graphs. It's not clear to
me what these views will contain. Since they are not essential for
SQL/PGQ functionality, I have not implemented them.

+ /*
+ * Now check number and names.
+ *
+ * XXX We could provide more detail in the error messages, but that would
+ * probably only be useful for some ALTER commands, because otherwise it's
+ * not really clear which label definition is the wrong one, and so you'd
+ * have to construct a rather verbose report to be of any use. Let's keep
+ * it simple for now.
+ */

Agree with XXX. I think the code is good enough as is. We can leave
XXX there in case we expect someone to improve it in future. Otherwise
we should remove XXX as well.

+
+ rel = table_open(PropgraphLabelPropertyRelationId, RowShareLock);
+ ScanKeyInit(&key[0],
+ Anum_pg_propgraph_label_property_plppropid,
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(propoid));
+ scan = systable_beginscan(rel, InvalidOid /* FIXME */ ,
+ true, NULL, 1, key);

I think the FIXME is to add the correct index OID.
pg_propgraph_label_property_label_prop_index contains plppropid as a
key but it's not the first column. So probably some other, yet not
defined, index is expected here?

+ALTER PROPERTY GRAPH g3 ALTER VERTEX TABLE t3 DROP LABEL t3l3;
+ALTER PROPERTY GRAPH g3 DROP VERTEX TABLES (t2); -- fail (TODO:
dubious error message)
+ERROR: cannot drop vertex t2 of property graph g3 because other
objects depend on it
+DETAIL: edge e1 of property graph g3 depends on vertex t2 of property graph g3
+HINT: Use DROP ... CASCADE to drop the dependent objects too.

I don't see what's dubious about this error message. edge e1 connects
t2 and t1. Dropping t2 would leave e1 dangling; error is preventing
it. Looks similar to how we prevent a referenced table being dropped.
Or is it expected that e1 be dropped without specifying cascade when
t2 is dropped since e1 has no existence without t2?

Also the patchset fixes the CI failure from the previous patchset.

The patches are reordered slightly. Each patch contains a commit
message that explains the changes in that patch.

[1] https://www.postgresql.org/message-id/CAExHW5sM+ZGVzR1428FsDHuWc-FU2-6zQr5j91KLh6vZaWY0ow@mail.gmail.com





--
Best Wishes,
Ashutosh Bapat

  62. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-08-11T13:42:55Z

    I have browsed this patch set a bit to get myself up to date.

General thoughts:

This is a large patch set, and it's not going to be perfect at the first 
try.  Especially, some of the parsing rules, query semantics, that kind 
of thing.  So I'm thinking that we should aim at integrating this with 
an understanding that it would be somewhat experimental, and then 
iterate on some of the details in the tree.  Obviously, that would still 
require that the overall architecture is ok, that it doesn't crash, that 
it satisfies security requirements.  Also, it should as much as possible 
follow the "if you don't use it, it doesn't affect you" rule.  So I'm 
specifically looking at where the patch intersects with existing code in 
critical ways, especially in parse analysis.  I want to spend more time 
reviewing that in particular.  Much of the rest of patch is 
almost-boilerplate: New DDL commands, new catalogs, associated tests and 
documentation.  It looks a lot, but most of it is not very surprising.

I found two areas where a bit more work could be done to separate the 
new code from existing code:

src/backend/utils/cache/inval.c: This looks suspicious.  The existing 
code only deals with very fundamental catalogs such as pg_class and 
pg_index.  It doesn't feel right to hardcode additional arguably very 
high-level PGQ-related catalogs there.  We should think of a different 
approach here.

src/test/regress/sql/rowsecurity.sql: I think it would be better to 
separate the new test cases into a separate file.  This test file is 
already large and complicated, and sprinkling a bunch of more stuff all 
over the place is going to make review and maintenance more complicated.

We also need to make sure that property graphs have security features 
equivalent to views.  For example, I suspect we need to integrate them 
with restrict_nonsystem_relation_kind.  There might be other similar 
things, to be checked.

  63. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-08-18T11:31:48Z

    Hi Peter,

On Mon, Aug 11, 2025 at 7:12 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> I have browsed this patch set a bit to get myself up to date.
>
> General thoughts:
>
> This is a large patch set, and it's not going to be perfect at the first
> try.  Especially, some of the parsing rules, query semantics, that kind
> of thing.  So I'm thinking that we should aim at integrating this with
> an understanding that it would be somewhat experimental, and then
> iterate on some of the details in the tree.

FWIW, I agree with this plan.

> Obviously, that would still
> require that the overall architecture is ok, that it doesn't crash, that
> it satisfies security requirements.  Also, it should as much as possible
> follow the "if you don't use it, it doesn't affect you" rule.

+1.

>
> I found two areas where a bit more work could be done to separate the
> new code from existing code:
>
> src/backend/utils/cache/inval.c: This looks suspicious.  The existing
> code only deals with very fundamental catalogs such as pg_class and
> pg_index.  It doesn't feel right to hardcode additional arguably very
> high-level PGQ-related catalogs there.  We should think of a different
> approach here.

I implemented it that way considering similarity between properties
and attributes. But I agree with you. I think it's a matter of calling
CacheInvalidateRelcacheByRelid with OID of property graph at
appropriate places in AlterPropGraph(), which is the only place where
components of the property graph are changed without changing property
graph's pg_class tuple. Creating and dropping a property graph will
touch the pg_class tuple which will trigger the current invalidation
mechanism.

>
> We also need to make sure that property graphs have security features
> equivalent to views.  For example, I suspect we need to integrate them
> with restrict_nonsystem_relation_kind.  There might be other similar
> things, to be checked.
>

Thanks for pointing me to restrict_nonsystem_relation_kind. I can take
care of that. Apart from that views have two security related settings
- security_invoker and security_barrier.

As mentioned in the commit message of 0003, property graphs behave
like views with security_invoker set to true. This will avoid any
privilege escalations through property graphs. This should be the
safest MVP. But it's different from the default security_invoker
setting for views. I was thinking that we will integrate the patches
with this behaviour and add security_invoker semantics in the next
iteration. Please let me know if you think that security_invoker and
security_definer semantics should both be supported before the first
commit itself.

Property graphs do not have security_barrier setting right now.
Property graphs do not have any conditions of their own. But
GRAPH_TABLE() may have. WHERE conditions in the GRAPH_TABLE are
executed like other conditions on the underlying table (if our
optimizer can push the conditions below UNION). I guess we need to
support security_barrier semantics on property graph so that WHERE
conditions in GRAPH_TABLE are executed before other conditions, but it
doesn't seem to be critical to me for the first cut as users can
leverage security_barrier views for the same, if required. But please
let me know if you think that security_barrier semantics should also
be supported before the first commit.

RLS is already covered.

Is there anything that is missing?

>
> src/test/regress/sql/rowsecurity.sql: I think it would be better to
> separate the new test cases into a separate file.  This test file is
> already large and complicated, and sprinkling a bunch of more stuff all
> over the place is going to make review and maintenance more complicated.

I sprinkled the queries in that file since the tables, RLS rules,
scenarios to test were readily available there. But I agree with you
that a file would be better. In fact, it's better to create a separate
file graph_table_security.sql for tests related to security aspects of
property graph covering RLS, restrict_nonsystem_relation_kind,
security_invoker and security_barrier. What do you think? I will work
on that.

From the first sentence in this email, it seems that you are planning
a thorough review of this patch set. Are you waiting for the above
issues to be addressed before continuing the review?

--
Best Wishes,
Ashutosh Bapat

  64. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-08-31T11:05:19Z

    Hi Ashutosh,

Thanks for the new patch set.

On Thu, Aug 7, 2025 at 6:47 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Hi Amit,
> Thanks for your comments
>
> On Wed, Jul 23, 2025 at 2:08 PM Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > Hi Ashutosh,
> >
> > On Tue, Jul 22, 2025 at 8:40 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > > Here's the patchset rebased on the latest master.
> >
> > Thanks for the update. I was going through the patch series today and
> > had a few comments on the structure that might help with reviewing and
> > eventually committing, whoever ends up doing that. :)
> >
> > I noticed that some functions, like graph_table_property_reference(),
> > are introduced in one patch and then renamed or removed in a later
> > one. It’s easier to review if such refactoring is avoided across
> > patches -- ideally, each patch should introduce code in its final
> > intended form. That also helps reduce the number of patches and makes
> > each one more self-contained.
> >
> > One of the later patches (0004) collects several follow-up changes.
> > While it fixes a real bug -- a crash when GRAPH_TABLE is used inside
> > plpgsql due to a conflict with the columnref hook -- it also includes
> > incidental cleanups like switching to foreach_node(), updating
> > comments, and adjusting function signatures. Those would be better
> > folded into the patches that introduced the relevant code, rather than
> > grouped into a catch-all at the end. That keeps each patch focused and
> > easier to review -- and easier to merge when committing.
> >
> > A general principle that might help: if you're refactoring existing
> > code, a standalone preliminary patch makes sense. But if you're
> > tweaking something just added in the same series, it’s usually better
> > to squash that into the original patch. The rename from
> > graph_table_property_reference() to transformGraphTablePropertyRef()
> > may be a fair exception since it reflects a shift prompted by the bug
> > fix -- but most other adjustments could be folded in without loss of
> > clarity.
> >
> > I understand the intent to spell out each change, but if the details
> > are incidental to the overall design, they don’t necessarily need to
> > be split out. Explaining the reasoning in the thread is always
> > helpful, but consolidating the patches once the design has settled
> > makes things easier for both reviewers and committers.
>
> 0001 is almost the same patch that Peter posted almost a year ago.
> Each of 0002 onwards patches contains logically grouped changes. I
> have changed 0001 minimally (so that it continues to apply, compile
> and pass regression). I think this arrangement will make it easy for
> Peter to review the changes. It will help him understand what all
> changed since 0001 and each change in its own context. That has led to
> a lot of overlap between 0002 and 0001 which I think should be
> squashed together even now. But I would like to know what Peter thinks
> - what would make his review easier. This arrangement might also help
> Junwang, who has reviewed some patches, to continue his incremental
> review.
>
> I have rearranged the patches 0002 to 0014 so that the same change
> isn't revised in multiple patches. Hope that helps.
>
> I am also attaching a single patch as well to this email, so that
> newer reviewers can review the changes as a whole.
>
> SQL_PGQ_20250807.zip is separate patches zipped together.
> SQL_PGQ_one_patch_20250807.zip is a single diff with changes from all
> the patches squashed together. It's still zipped to avoid the email
> being held for moderation.
>
> >
> > Finally, attaching the patches directly, with versioned names like
> > v8-000x, instead of zipping them helps.  Many folks (myself included)
> > will casually skip a zip file because of the small hassle of unzipping
> > just to read a patch. I once postponed reading such a patch and didn’t
> > get back to it for quite a while. :)
>
> I used to attach those as separate patches till [1], but after that
> the total size of the patchset grew so much that my emails used to get
> held back for moderation. So I started attaching zip files. The
> increase in size is mostly due to the 0014 patch. If we think that
> it's not needed or can be trimmed down, we will be able to attach the
> patchset as separate attachments.
>
> Here's what changed between the last patchset and this
>
> 0001 has some TODOs, FIXMEs and XXXs. I and Junwang had fixed some of
> them earlier. This patchset fixes some more. Below is my analysis of
> each of them.
> +
> + <!-- TODO: multiple path patterns in a graph pattern (comma-separated) -->
> +
> + <!-- TODO: quantifiers -->
>
> I think we should remove these TODOs since we are not going to support
> these cases in this patchset. We will add the documentation when we
> implement these features.
>
> +/*
> + * 15.2
> + * PG_DEFINED_LABEL_SETS view
> + */
> +
> +-- TODO
> +
> +
> +/*
> + * 15.3
> + * PG_DEFINED_LABEL_SET_LABELS view
> + */
> +
> +-- TODO
> +
> +
> +/*
> + * 15.4
> + * PG_EDGE_DEFINED_LABEL_SETS view
> + */
> +
> +-- TODO
> +
> +/*
> + * 15.6
> + * PG_EDGE_TRIPLETS view
> + */
> +
> +-- TODO
> +
> +/*
> + * 15.15
> + * PG_VERTEX_DEFINED_LABEL_SETS view
> + */
> +
> +-- TODO
>
> All these views are related to the defined label set. IIUC, defined
> label set is a set of labels which is shared by multiple edges or
> vertices of a property graph. Please note it's the whole set shared;
> not just individual labels in the set. In that sense, I think, the
> labels associated with each edge or vertex table in a property graph
> form a defined label set. That way the property graph element's OID
> becomes the defined label set's identifier. I am not sure if this view
> has any practical use for tabular property graphs. It's not clear to
> me what these views will contain. Since they are not essential for
> SQL/PGQ functionality, I have not implemented them.
>
> + /*
> + * Now check number and names.
> + *
> + * XXX We could provide more detail in the error messages, but that would
> + * probably only be useful for some ALTER commands, because otherwise it's
> + * not really clear which label definition is the wrong one, and so you'd
> + * have to construct a rather verbose report to be of any use. Let's keep
> + * it simple for now.
> + */
>
> Agree with XXX. I think the code is good enough as is. We can leave
> XXX there in case we expect someone to improve it in future. Otherwise
> we should remove XXX as well.
>
> +
> + rel = table_open(PropgraphLabelPropertyRelationId, RowShareLock);
> + ScanKeyInit(&key[0],
> + Anum_pg_propgraph_label_property_plppropid,
> + BTEqualStrategyNumber, F_OIDEQ,
> + ObjectIdGetDatum(propoid));
> + scan = systable_beginscan(rel, InvalidOid /* FIXME */ ,
> + true, NULL, 1, key);
>
> I think the FIXME is to add the correct index OID.
> pg_propgraph_label_property_label_prop_index contains plppropid as a
> key but it's not the first column. So probably some other, yet not
> defined, index is expected here?
>
> +ALTER PROPERTY GRAPH g3 ALTER VERTEX TABLE t3 DROP LABEL t3l3;
> +ALTER PROPERTY GRAPH g3 DROP VERTEX TABLES (t2); -- fail (TODO:
> dubious error message)
> +ERROR: cannot drop vertex t2 of property graph g3 because other
> objects depend on it
> +DETAIL: edge e1 of property graph g3 depends on vertex t2 of property graph g3
> +HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> I don't see what's dubious about this error message. edge e1 connects
> t2 and t1. Dropping t2 would leave e1 dangling; error is preventing
> it. Looks similar to how we prevent a referenced table being dropped.
> Or is it expected that e1 be dropped without specifying cascade when
> t2 is dropped since e1 has no existence without t2?
>
> Also the patchset fixes the CI failure from the previous patchset.
>
> The patches are reordered slightly. Each patch contains a commit
> message that explains the changes in that patch.
>
> [1] https://www.postgresql.org/message-id/CAExHW5sM+ZGVzR1428FsDHuWc-FU2-6zQr5j91KLh6vZaWY0ow@mail.gmail.com
>
>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat

I have some review comments, and hope some of them are helpful.

1.

doc/src/sgml/ddl.sgml

+<programlisting>
+CREATE PROPERTY GRAPH myshop
+    VERTEX TABLES (
+        products LABEL product,
+        customers LABEL customer,
+        orders LABEL order
+    )
+    EDGE TABLES (
+        order_items SOURCE orders DESTINATION products LABEL contains,
+        customer_orders SOURCE customers DESTINATION orders LABEL has
+    );
+</programlisting>

order is a reserved keyword, so the following example will fail, we
should not give a wrong example in our document.

2.

doc/src/sgml/information_schema.sgml

+  <title><literal>pg_element_table_key_columns</literal></title>
+
+  <para>
+   The view <literal>pg_element_key_columns</literal> identifies which columns
+   are part of the keys of the element tables of property graphs defined in
+   the current database.  Only those property graphs are shown that the
+   current user has access to (by way of being the owner or having some
+   privilege).
+  </para>


+  <title><literal>pg_element_table_properties</literal></title>
+
+  <para>
+   The view <literal>pg_element_table_labels</literal> shows the definitions
+   of the properties for the element tables of property graphs defined in the
+   current database.  Only those property graphs are shown that the current
+   user has access to (by way of being the owner or having some privilege).
+  </para>

the <title> and the <para> doesn't match.

3.

doc/src/sgml/queries.sgml

+   <para>
+    A path pattern thus matches a sequence of vertices and edges.  The
+    simplest possible path pattern is
+<programlisting>
+()
+</programlisting>
+    which matches a single vertex.  The next simplest pattern would be
+<programlisting>
+()-[]->()
+</programlisting>
+    which matches a vertex followed by an edge followed by a vertex.  The
+    characters <literal>()</literal> are a vertex pattern and the characters
+    <literal>-[]-></literal> are an edge pattern.
+   </para>

the description seems wrong, when a user writes (), it should match
all vertices in a property graph, for example:

explain SELECT customer_name FROM GRAPH_TABLE (myshop MATCH () COLUMNS
(1 AS customer_name));

[local] zjw@postgres:5432-73666=# explain SELECT customer_name FROM
GRAPH_TABLE (myshop MATCH () COLUMNS (1 AS customer_name));
                            QUERY PLAN
------------------------------------------------------------------
 Append  (cost=0.00..89.40 rows=3960 width=4)
   ->  Seq Scan on customers  (cost=0.00..18.50 rows=850 width=4)
   ->  Seq Scan on orders  (cost=0.00..32.60 rows=2260 width=4)
   ->  Seq Scan on products  (cost=0.00..18.50 rows=850 width=4)
(4 rows)

4.

doc/src/sgml/ref/create_property_graph.sgml

+<programlisting>
+CREATE PROPERTY GRAPH g1
+    VERTEX TABLES (
+        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 2)
+    ) ...
+</programlisting>
+      but this would not:
+<programlisting>
+CREATE PROPERTY GRAPH g1
+    VERTEX TABLES (
+        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 10)
+    ) ...
+</programlisting></para>

The expr after  PROPERTIES should be (a * 2 AS x)

5.

src/backend/catalog/sql_features.txt

+G034 Path concatenation YES SQL/PGQ required

Do we support path concatenation?

+G070 Label expression: label disjunction NO SQL/PGQ required

I think this should be a YES?

6.

src/backend/commands/tablecmds.c

The description RenameRelation and RemoveRelations should adapt
property graph, below are diffs I suggest:

 /*
- * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN TABLE
+ * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN
TABLE/PROPERTY GRAPH
  * RENAME
  */
 ObjectAddress
@@ -4210,8 +4210,8 @@ RenameRelation(RenameStmt *stmt)

        /*
         * Grab an exclusive lock on the target table, index, sequence, view,
-        * materialized view, or foreign table, which we will NOT release until
-        * end of transaction.
+        * materialized view, foreign table or property graph, which we will NOT
+        * release until end of transaction.


 /*
  * RemoveRelations
  *             Implements DROP TABLE, DROP INDEX, DROP SEQUENCE, DROP VIEW,
- *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE
+ *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE, DROP PROPERTY GRAPH

7.

src/backend/nodes/nodeFuncs.c

exprLocation should have an arm for T_GraphPropertyRef? I suggest:

@@ -1811,6 +1811,9 @@ exprLocation(const Node *expr)
                case T_PartitionRangeDatum:
                        loc = ((const PartitionRangeDatum *) expr)->location;
                        break;
+               case T_GraphPropertyRef:
+                       loc = ((const GraphPropertyRef *) expr)->location;
+                       break;

8.

src/backend/rewrite/rewriteGraphTable.c

patch 0002

+ /*
+ * Label expressions from two element patterns need to be
+ * conjucted. Label conjuction is not supported right now

typo, should be conjuncted and conjunction.

9.

The line length of some code is quite long, which isn't ideal, but
it's not a major issue. It can be formatted before being committed.

BTW, the patch set seems not to apply to the current master.

I will go another round of review of the test cases, thanks.

-- 
Regards
Junwang Zhao

  65. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-11-20T15:00:53Z

    Hi Junwang,

On Sun, Aug 31, 2025 at 4:35 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
>
> I have some review comments, and hope some of them are helpful.
>
> 1.
>
> doc/src/sgml/ddl.sgml
>
> +<programlisting>
> +CREATE PROPERTY GRAPH myshop
> +    VERTEX TABLES (
> +        products LABEL product,
> +        customers LABEL customer,
> +        orders LABEL order
> +    )
> +    EDGE TABLES (
> +        order_items SOURCE orders DESTINATION products LABEL contains,
> +        customer_orders SOURCE customers DESTINATION orders LABEL has
> +    );
> +</programlisting>
>
> order is a reserved keyword, so the following example will fail, we
> should not give a wrong example in our document.
>

I tried those examples and they all worked. What error are you
getting? What is not working for you?

> 2.
>
> doc/src/sgml/information_schema.sgml
>
> +  <title><literal>pg_element_table_key_columns</literal></title>
> +
> +  <para>
> +   The view <literal>pg_element_key_columns</literal> identifies which columns
> +   are part of the keys of the element tables of property graphs defined in
> +   the current database.  Only those property graphs are shown that the
> +   current user has access to (by way of being the owner or having some
> +   privilege).
> +  </para>
>
>
> +  <title><literal>pg_element_table_properties</literal></title>
> +
> +  <para>
> +   The view <literal>pg_element_table_labels</literal> shows the definitions
> +   of the properties for the element tables of property graphs defined in the
> +   current database.  Only those property graphs are shown that the current
> +   user has access to (by way of being the owner or having some privilege).
> +  </para>
>
> the <title> and the <para> doesn't match.

Don't understand this. What isn't matching here. May be provide a
patch with what you think is correct.

>
> 3.
>
> doc/src/sgml/queries.sgml
>
> +   <para>
> +    A path pattern thus matches a sequence of vertices and edges.  The
> +    simplest possible path pattern is
> +<programlisting>
> +()
> +</programlisting>
> +    which matches a single vertex.  The next simplest pattern would be
> +<programlisting>
> +()-[]->()
> +</programlisting>
> +    which matches a vertex followed by an edge followed by a vertex.  The
> +    characters <literal>()</literal> are a vertex pattern and the characters
> +    <literal>-[]-></literal> are an edge pattern.
> +   </para>
>
> the description seems wrong, when a user writes (), it should match
> all vertices in a property graph, for example:

This description is a continuation of the previous sentence. It should
be read as "() which matches a single vertex (in a sequence of
vertices and edges)."  See how the next sentence is written. This
looks ok to me.

>
> 4.
>
> doc/src/sgml/ref/create_property_graph.sgml
>
> +<programlisting>
> +CREATE PROPERTY GRAPH g1
> +    VERTEX TABLES (
> +        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 2)
> +    ) ...
> +</programlisting>
> +      but this would not:
> +<programlisting>
> +CREATE PROPERTY GRAPH g1
> +    VERTEX TABLES (
> +        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 10)
> +    ) ...
> +</programlisting></para>
>
> The expr after  PROPERTIES should be (a * 2 AS x)

Good catch. Fixed.

>
> 5.
>
> src/backend/catalog/sql_features.txt
>
> +G034 Path concatenation YES SQL/PGQ required
>
> Do we support path concatenation?

I don't think so. But let Peter confirm it.

>
> +G070 Label expression: label disjunction NO SQL/PGQ required
>
> I think this should be a YES?

Nice catch. Fixed.

>
> 6.
>
> src/backend/commands/tablecmds.c
>
> The description RenameRelation and RemoveRelations should adapt
> property graph, below are diffs I suggest:
>
>  /*
> - * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN TABLE
> + * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN
> TABLE/PROPERTY GRAPH
>   * RENAME
>   */
>  ObjectAddress
> @@ -4210,8 +4210,8 @@ RenameRelation(RenameStmt *stmt)
>
>         /*
>          * Grab an exclusive lock on the target table, index, sequence, view,
> -        * materialized view, or foreign table, which we will NOT release until
> -        * end of transaction.
> +        * materialized view, foreign table or property graph, which we will NOT
> +        * release until end of transaction.
>
>
>  /*
>   * RemoveRelations
>   *             Implements DROP TABLE, DROP INDEX, DROP SEQUENCE, DROP VIEW,
> - *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE
> + *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE, DROP PROPERTY GRAPH
>

Nice catch. Fixed.

> 7.
>
> src/backend/nodes/nodeFuncs.c
>
> exprLocation should have an arm for T_GraphPropertyRef? I suggest:
>
> @@ -1811,6 +1811,9 @@ exprLocation(const Node *expr)
>                 case T_PartitionRangeDatum:
>                         loc = ((const PartitionRangeDatum *) expr)->location;
>                         break;
> +               case T_GraphPropertyRef:
> +                       loc = ((const GraphPropertyRef *) expr)->location;
> +                       break;
>
> 8.
>
> src/backend/rewrite/rewriteGraphTable.c
>
> patch 0002
>
> + /*
> + * Label expressions from two element patterns need to be
> + * conjucted. Label conjuction is not supported right now
>
> typo, should be conjuncted and conjunction.

Done and improved that comment a bit.

Attaching the patchset with the next email.

-- 
Best Wishes,
Ashutosh Bapat

  66. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-11-20T15:13:16Z

    Hi,
Sending the email again since my earlier email was held for moderation
because of patchset size. Attached as a zip here.

On Thu, Nov 20, 2025 at 8:31 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Mon, Aug 18, 2025 at 5:01 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>
> >
> > >
> > > I found two areas where a bit more work could be done to separate the
> > > new code from existing code:
> > >
> > > src/backend/utils/cache/inval.c: This looks suspicious.  The existing
> > > code only deals with very fundamental catalogs such as pg_class and
> > > pg_index.  It doesn't feel right to hardcode additional arguably very
> > > high-level PGQ-related catalogs there.  We should think of a different
> > > approach here.
> >
> > I implemented it that way considering similarity between properties
> > and attributes. But I agree with you. I think it's a matter of calling
> > CacheInvalidateRelcacheByRelid with OID of property graph at
> > appropriate places in AlterPropGraph(), which is the only place where
> > components of the property graph are changed without changing property
> > graph's pg_class tuple. Creating and dropping a property graph will
> > touch the pg_class tuple which will trigger the current invalidation
> > mechanism.
> >
>
> Done.
>
> > >
> > > We also need to make sure that property graphs have security features
> > > equivalent to views.  For example, I suspect we need to integrate them
> > > with restrict_nonsystem_relation_kind.  There might be other similar
> > > things, to be checked.
> > >
> >
> > Thanks for pointing me to restrict_nonsystem_relation_kind. I can take
> > care of that.
>
> Reading commit message of 66e94448abec3aad04faf0a79cab4881ae08e08a
> which introduced this GUC and CVE
> https://www.postgresql.org/support/security/CVE-2024-7348/, it does
> not seem likely that property graphs can be used that way. SELECT *
> FROM <property graph> will end up in an error. A property graph
> reference is allowed only in GRAPH_TABLE(), which pg_dump does not
> use. Do you have something else in mind?
>
> As part of this investigation, I found that a property graph reference
> outside GRAPH_TABLE does throw error, but from unexpected places.
> Added error messages in addRangeTableEntry and
> addRangeTableEntryForRelation instead.
>
> > Apart from that views have two security related settings
> > - security_invoker and security_barrier.
> >
> > As mentioned in the commit message of 0003, property graphs behave
> > like views with security_invoker set to true. This will avoid any
> > privilege escalations through property graphs. This should be the
> > safest MVP. But it's different from the default security_invoker
> > setting for views. I was thinking that we will integrate the patches
> > with this behaviour and add security_invoker semantics in the next
> > iteration. Please let me know if you think that security_invoker and
> > security_definer semantics should both be supported before the first
> > commit itself.
> >
> > Property graphs do not have security_barrier setting right now.
> > Property graphs do not have any conditions of their own. But
> > GRAPH_TABLE() may have. WHERE conditions in the GRAPH_TABLE are
> > executed like other conditions on the underlying table (if our
> > optimizer can push the conditions below UNION). I guess we need to
> > support security_barrier semantics on property graph so that WHERE
> > conditions in GRAPH_TABLE are executed before other conditions, but it
> > doesn't seem to be critical to me for the first cut as users can
> > leverage security_barrier views for the same, if required. But please
> > let me know if you think that security_barrier semantics should also
> > be supported before the first commit.
> >
> > RLS is already covered.
> >
> > Is there anything that is missing?
>
> Waiting for your response here.
>
>
> >
> > >
> > > src/test/regress/sql/rowsecurity.sql: I think it would be better to
> > > separate the new test cases into a separate file.  This test file is
> > > already large and complicated, and sprinkling a bunch of more stuff all
> > > over the place is going to make review and maintenance more complicated.
> >
> > I sprinkled the queries in that file since the tables, RLS rules,
> > scenarios to test were readily available there. But I agree with you
> > that a file would be better. In fact, it's better to create a separate
> > file graph_table_security.sql for tests related to security aspects of
> > property graph covering RLS, restrict_nonsystem_relation_kind,
> > security_invoker and security_barrier. What do you think? I will work
> > on that.
>
> Done. Added a new test file graph_table_rls.sql. in 0012.
>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Best Wishes,
Ashutosh Bapat

  67. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-11-24T02:31:14Z

    Hi Ashutosh,

On Thu, Nov 20, 2025 at 11:01 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Hi Junwang,
>
> On Sun, Aug 31, 2025 at 4:35 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> >
> > I have some review comments, and hope some of them are helpful.
> >
> > 1.
> >
> > doc/src/sgml/ddl.sgml
> >
> > +<programlisting>
> > +CREATE PROPERTY GRAPH myshop
> > +    VERTEX TABLES (
> > +        products LABEL product,
> > +        customers LABEL customer,
> > +        orders LABEL order
> > +    )
> > +    EDGE TABLES (
> > +        order_items SOURCE orders DESTINATION products LABEL contains,
> > +        customer_orders SOURCE customers DESTINATION orders LABEL has
> > +    );
> > +</programlisting>
> >
> > order is a reserved keyword, so the following example will fail, we
> > should not give a wrong example in our document.
> >
>
> I tried those examples and they all worked. What error are you
> getting? What is not working for you?

Here is what I got, pay attention to the queries with singular `order`, it's a
reserved keyword.

[local] zjw@postgres:5432-24494=# CREATE PROPERTY GRAPH myshop
      VERTEX TABLES (
          products LABEL product,
          customers LABEL customer,
          orders LABEL order
      )
      EDGE TABLES (
          order_items SOURCE orders DESTINATION products LABEL contains,
          customer_orders SOURCE customers DESTINATION orders LABEL has
      );
ERROR:  syntax error at or near "order"
LINE 5:         orders LABEL order
                                            ^
Time: 1.369 ms

[local] zjw@postgres:5432-24494=# SELECT customer_name FROM
GRAPH_TABLE (myshop MATCH (c:customer)-[:has]->(o:order WHERE
o.ordered_when = current_date) COLUMNS (c.name AS customr_name));
ERROR:  syntax error at or near "order"
LINE 1: ...GRAPH_TABLE (myshop MATCH (c:customer)-[:has]->(o:order WHER...

                                     ^
Time: 0.999 ms

>
> > 2.
> >
> > doc/src/sgml/information_schema.sgml
> >
> > +  <title><literal>pg_element_table_key_columns</literal></title>
> > +
> > +  <para>
> > +   The view <literal>pg_element_key_columns</literal> identifies which columns
> > +   are part of the keys of the element tables of property graphs defined in
> > +   the current database.  Only those property graphs are shown that the
> > +   current user has access to (by way of being the owner or having some
> > +   privilege).
> > +  </para>
> >
> >
> > +  <title><literal>pg_element_table_properties</literal></title>
> > +
> > +  <para>
> > +   The view <literal>pg_element_table_labels</literal> shows the definitions
> > +   of the properties for the element tables of property graphs defined in the
> > +   current database.  Only those property graphs are shown that the current
> > +   user has access to (by way of being the owner or having some privilege).
> > +  </para>
> >
> > the <title> and the <para> doesn't match.
>
> Don't understand this. What isn't matching here. May be provide a
> patch with what you think is correct.

I checked this again, I think I'm wrong about this, sorry about that.

>
> >
> > 3.
> >
> > doc/src/sgml/queries.sgml
> >
> > +   <para>
> > +    A path pattern thus matches a sequence of vertices and edges.  The
> > +    simplest possible path pattern is
> > +<programlisting>
> > +()
> > +</programlisting>
> > +    which matches a single vertex.  The next simplest pattern would be
> > +<programlisting>
> > +()-[]->()
> > +</programlisting>
> > +    which matches a vertex followed by an edge followed by a vertex.  The
> > +    characters <literal>()</literal> are a vertex pattern and the characters
> > +    <literal>-[]-></literal> are an edge pattern.
> > +   </para>
> >
> > the description seems wrong, when a user writes (), it should match
> > all vertices in a property graph, for example:
>
> This description is a continuation of the previous sentence. It should
> be read as "() which matches a single vertex (in a sequence of
> vertices and edges)."  See how the next sentence is written. This
> looks ok to me.

Sure, WFM.

>
> >
> > 4.
> >
> > doc/src/sgml/ref/create_property_graph.sgml
> >
> > +<programlisting>
> > +CREATE PROPERTY GRAPH g1
> > +    VERTEX TABLES (
> > +        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 2)
> > +    ) ...
> > +</programlisting>
> > +      but this would not:
> > +<programlisting>
> > +CREATE PROPERTY GRAPH g1
> > +    VERTEX TABLES (
> > +        v1 LABEL foo PROPERTIES (x AS a * 2) LABEL bar PROPERTIES (x AS a * 10)
> > +    ) ...
> > +</programlisting></para>
> >
> > The expr after  PROPERTIES should be (a * 2 AS x)
>
> Good catch. Fixed.
>
> >
> > 5.
> >
> > src/backend/catalog/sql_features.txt
> >
> > +G034 Path concatenation YES SQL/PGQ required
> >
> > Do we support path concatenation?
>
> I don't think so. But let Peter confirm it.
>
> >
> > +G070 Label expression: label disjunction NO SQL/PGQ required
> >
> > I think this should be a YES?
>
> Nice catch. Fixed.
>
> >
> > 6.
> >
> > src/backend/commands/tablecmds.c
> >
> > The description RenameRelation and RemoveRelations should adapt
> > property graph, below are diffs I suggest:
> >
> >  /*
> > - * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN TABLE
> > + * Execute ALTER TABLE/INDEX/SEQUENCE/VIEW/MATERIALIZED VIEW/FOREIGN
> > TABLE/PROPERTY GRAPH
> >   * RENAME
> >   */
> >  ObjectAddress
> > @@ -4210,8 +4210,8 @@ RenameRelation(RenameStmt *stmt)
> >
> >         /*
> >          * Grab an exclusive lock on the target table, index, sequence, view,
> > -        * materialized view, or foreign table, which we will NOT release until
> > -        * end of transaction.
> > +        * materialized view, foreign table or property graph, which we will NOT
> > +        * release until end of transaction.
> >
> >
> >  /*
> >   * RemoveRelations
> >   *             Implements DROP TABLE, DROP INDEX, DROP SEQUENCE, DROP VIEW,
> > - *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE
> > + *             DROP MATERIALIZED VIEW, DROP FOREIGN TABLE, DROP PROPERTY GRAPH
> >
>
> Nice catch. Fixed.
>
> > 7.
> >
> > src/backend/nodes/nodeFuncs.c
> >
> > exprLocation should have an arm for T_GraphPropertyRef? I suggest:
> >
> > @@ -1811,6 +1811,9 @@ exprLocation(const Node *expr)
> >                 case T_PartitionRangeDatum:
> >                         loc = ((const PartitionRangeDatum *) expr)->location;
> >                         break;
> > +               case T_GraphPropertyRef:
> > +                       loc = ((const GraphPropertyRef *) expr)->location;
> > +                       break;
> >
> > 8.
> >
> > src/backend/rewrite/rewriteGraphTable.c
> >
> > patch 0002
> >
> > + /*
> > + * Label expressions from two element patterns need to be
> > + * conjucted. Label conjuction is not supported right now
> >
> > typo, should be conjuncted and conjunction.
>
> Done and improved that comment a bit.
>
> Attaching the patchset with the next email.
>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  68. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-11-24T05:00:13Z

    Hi Junwang,

On Mon, Nov 24, 2025 at 8:01 AM Junwang Zhao <zhjwpku@gmail.com> wrote:
>
> Hi Ashutosh,
>
> On Thu, Nov 20, 2025 at 11:01 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > Hi Junwang,
> >
> > On Sun, Aug 31, 2025 at 4:35 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > >
> > >
> > > I have some review comments, and hope some of them are helpful.
> > >
> > > 1.
> > >
> > > doc/src/sgml/ddl.sgml
> > >
> > > +<programlisting>
> > > +CREATE PROPERTY GRAPH myshop
> > > +    VERTEX TABLES (
> > > +        products LABEL product,
> > > +        customers LABEL customer,
> > > +        orders LABEL order
> > > +    )
> > > +    EDGE TABLES (
> > > +        order_items SOURCE orders DESTINATION products LABEL contains,
> > > +        customer_orders SOURCE customers DESTINATION orders LABEL has
> > > +    );
> > > +</programlisting>
> > >
> > > order is a reserved keyword, so the following example will fail, we
> > > should not give a wrong example in our document.
> > >
> >
> > I tried those examples and they all worked. What error are you
> > getting? What is not working for you?
>
> Here is what I got, pay attention to the queries with singular `order`, it's a
> reserved keyword.

I see it now. Sorry for missing it earlier.

I think something like attached should fix the problem, if we want to
continue with the current example. FWIW, it demos that quotes can be
used with labels, but we don't necessarily do that with other objects.
I am not sure whether Peter would like to continue with the example or
use a different one avoiding this subtlety altogether. Hence not
including it in the overall patchset.


-- 
Best Wishes,
Ashutosh Bapat

  69. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-11-24T06:03:47Z

    On Mon, Nov 24, 2025 at 1:00 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Hi Junwang,
>
> On Mon, Nov 24, 2025 at 8:01 AM Junwang Zhao <zhjwpku@gmail.com> wrote:
> >
> > Hi Ashutosh,
> >
> > On Thu, Nov 20, 2025 at 11:01 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > Hi Junwang,
> > >
> > > On Sun, Aug 31, 2025 at 4:35 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> > > >
> > > >
> > > > I have some review comments, and hope some of them are helpful.
> > > >
> > > > 1.
> > > >
> > > > doc/src/sgml/ddl.sgml
> > > >
> > > > +<programlisting>
> > > > +CREATE PROPERTY GRAPH myshop
> > > > +    VERTEX TABLES (
> > > > +        products LABEL product,
> > > > +        customers LABEL customer,
> > > > +        orders LABEL order
> > > > +    )
> > > > +    EDGE TABLES (
> > > > +        order_items SOURCE orders DESTINATION products LABEL contains,
> > > > +        customer_orders SOURCE customers DESTINATION orders LABEL has
> > > > +    );
> > > > +</programlisting>
> > > >
> > > > order is a reserved keyword, so the following example will fail, we
> > > > should not give a wrong example in our document.
> > > >
> > >
> > > I tried those examples and they all worked. What error are you
> > > getting? What is not working for you?
> >
> > Here is what I got, pay attention to the queries with singular `order`, it's a
> > reserved keyword.
>
> I see it now. Sorry for missing it earlier.
>
> I think something like attached should fix the problem, if we want to
> continue with the current example. FWIW, it demos that quotes can be
> used with labels, but we don't necessarily do that with other objects.
> I am not sure whether Peter would like to continue with the example or
> use a different one avoiding this subtlety altogether. Hence not
> including it in the overall patchset.
>

The patch WFM. Using a different one also works, maybe we can adopt
part of the schema from LDBC SNB [1]

[1] https://ldbcouncil.org/benchmarks/snb/


>
> --
> Best Wishes,
> Ashutosh Bapat



-- 
Regards
Junwang Zhao

  70. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-25T13:52:21Z

    I have done a rough review of the patch set version 20251120.

- There are "No newline at end of file" warnings from git diff for a 
couple of files:

       contrib/pg_overexplain/sql/pg_overexplain.sql
       src/test/regress/sql/graph_table_rls.sql

Please fix those in the next patch set, and maybe check your editor 
settings.

- Attached are two small patches with some small fixes I found in 
passing.  (I think some of them were also reported by Junwang Zhao in 
the meantime.)

- In the test files, especially src/test/regress/sql/graph_table.sql, 
there are wildly different SQL styles (capitalization, formatting) used, 
depending on who added the test case (I guess).  Let's keep that more 
consistent.

- In src/backend/parser/analyze.c, the extracted function 
constructSetOpTargetlist() needs a detailed comment.

- I'm not so sure about the semantics chosen in the patch "Access 
permissions on property graph".  I think according to the SQL standard, 
once you have access to the property graph, you don't need access to the 
underlying tables as well.  I guess you did this to align with how views 
work?  We might need to think about this a bit more, and document 
whatever the conclusion is.  But for now it's just small amount of code 
affected.

I think you could collapse all the patches into one patch now.  I have 
reviewed all the incremental patches and they all look ok to me.  I have 
made some notes about which things I want to review in more detail, such 
as the access control issue, but that doesn't need to be kept as a 
separate patch.

When you create future patches, consider using the git format-patch -v 
option.

And then you can also just gzip the patch.  That should make it even 
smaller than the .zip file.

  71. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-25T13:58:31Z

    On 20.11.25 16:00, Ashutosh Bapat wrote:
>> 5.
>>
>> src/backend/catalog/sql_features.txt
>>
>> +G034 Path concatenation YES SQL/PGQ required
>>
>> Do we support path concatenation?
> I don't think so. But let Peter confirm it.

AFAICT, path concatenation just allows that you can write multiple 
element patterns in a row, like ()-[]->().  I don't see how it could 
make sense to not support that.

  72. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-11-25T14:01:15Z

    On 24.11.25 06:00, Ashutosh Bapat wrote:
> I think something like attached should fix the problem, if we want to
> continue with the current example. FWIW, it demos that quotes can be
> used with labels, but we don't necessarily do that with other objects.
> I am not sure whether Peter would like to continue with the example or
> use a different one avoiding this subtlety altogether. Hence not
> including it in the overall patchset.

Let's just quote it.

I think this example set is nice because it is aligned with examples 
used elsewhere in the ddl.sgml chapter, such as foreign keys and as of 
recently temporal tables.

  73. Re: SQL Property Graph Queries (SQL/PGQ)

    Junwang Zhao <zhjwpku@gmail.com> — 2025-11-26T03:02:44Z

    On Tue, Nov 25, 2025 at 9:58 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 20.11.25 16:00, Ashutosh Bapat wrote:
> >> 5.
> >>
> >> src/backend/catalog/sql_features.txt
> >>
> >> +G034 Path concatenation YES SQL/PGQ required
> >>
> >> Do we support path concatenation?
> > I don't think so. But let Peter confirm it.
>
> AFAICT, path concatenation just allows that you can write multiple
> element patterns in a row, like ()-[]->().  I don't see how it could
> make sense to not support that.

Yeah, I just took a look at the SQL/PGQ standard

<path concatenation> ::=
    <path term> <path factor>

Now I understand, thanks.


-- 
Regards
Junwang Zhao

  74. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-02T06:56:15Z

    On Tue, Nov 25, 2025 at 7:28 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 20.11.25 16:00, Ashutosh Bapat wrote:
> >> 5.
> >>
> >> src/backend/catalog/sql_features.txt
> >>
> >> +G034 Path concatenation YES SQL/PGQ required
> >>
> >> Do we support path concatenation?
> > I don't think so. But let Peter confirm it.
>
> AFAICT, path concatenation just allows that you can write multiple
> element patterns in a row, like ()-[]->().  I don't see how it could
> make sense to not support that.

Ah! I confused path concatenation with either path pattern list or
path pattern multiset alternation. Sorry.

-- 
Best Wishes,
Ashutosh Bapat

  75. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-02T10:00:59Z

    On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> I have done a rough review of the patch set version 20251120.
>
> - There are "No newline at end of file" warnings from git diff for a
> couple of files:
>
>        contrib/pg_overexplain/sql/pg_overexplain.sql
>        src/test/regress/sql/graph_table_rls.sql
>
> Please fix those in the next patch set, and maybe check your editor
> settings.

I was assuming that pg_indent will fix it or at least git diff --check
will show it. But it seems only git diff shows it.

I am trying to find a way to automate the task of detection of such
warnings. Is `git diff | grep '^\\'` a good way to highlight the
existence of such warnings? It still won't show the file which
contains those warnings. I didn't find a non-cumbersome way to list
the files where such warnings exist. Any ideas?

>
> - Attached are two small patches with some small fixes I found in
> passing.  (I think some of them were also reported by Junwang Zhao in
> the meantime.)
>

Included in the attached patch.

> - In the test files, especially src/test/regress/sql/graph_table.sql,
> there are wildly different SQL styles (capitalization, formatting) used,
> depending on who added the test case (I guess).  Let's keep that more
> consistent.

Done. I have also fixed some inconsistent styles in
create_property_graph.sql and examined other modified SQL files. I
have done a couple rounds of fixing inconsistencies, so there
shouldn't be many (if not none) remaining now.

privileges.sql already uses inconsistent styles. The new changes there
just match the surrounding style.

Also removed the DROP SCHEMA statement from graph_table.sql and
create_property_graph.sql but left the command behind.

>
> - In src/backend/parser/analyze.c, the extracted function
> constructSetOpTargetlist() needs a detailed comment.

I have added a prologue to this function, describing what it does.
There are detailed comments in the function itself, which cover the
"how" and "why" part. Let me know if this suffices.

>
> - I'm not so sure about the semantics chosen in the patch "Access
> permissions on property graph".  I think according to the SQL standard,
> once you have access to the property graph, you don't need access to the
> underlying tables as well.  I guess you did this to align with how views
> work?  We might need to think about this a bit more, and document
> whatever the conclusion is.  But for now it's just small amount of code
> affected.

Section 7.1 Access rules seem to just require that the session user
should have SELECT privileges on the property graph. I didn't find an
answer to the question: What privileges should be used while accessing
the element tables. Application of RLS policies depends upon the
answer, for example. They  can be either the owner's privileges
(security_definer semantics) or the privileges of session user
(security_invoker semantics). A view can define what data it exposes
precisely upto a row and column; hence a security_definer view can be
made safer. But a property graph can not constrain rows that it
exposes. So I feel, by default, security_invoker semantics are safer
for property graphs. We may support security_definer semantics later,
but it has to be an explicit choice by the user.

There's another deviation from standard.

Section 11.19, Access rule 2 and General rule 4 talk about the
privileges on the element tables required by the owner of the property
graph. AFAIU, Access rule 2 and General Rule 4 together say that the
owner of the property graph (per Syntax rule 9), should have SELECT
permission on every column that is mentioned in the property graph
definition, SELECT permission on every element table. It does not
require the property graph owner to be the owner of the element
tables. But patch 0001, in the previous patchset, requires that the
owner of the property graph should be the owner of the element tables
or superuser.

Assume two users u1 and u2, both with CREATE permissions on schema public.
postgres@147235=#set session authorization u1;
SET
postgres@147235=#create table t1 (a int, b int);
CREATE TABLE
postgres@147235=#set session authorization u2;
SET
postgres@147235=#create property GRAPH g1 vertex tables (t1 key (a));
ERROR:  must be owner of table t1
postgres@147235=#set session authorization u1;
SET
postgres@147235=#create property GRAPH g1 vertex tables (t1 key (a));
CREATE PROPERTY GRAPH

However, the owner may transfer the ownership to another user who need
not be the owner of the element tables
#alter property graph g1 owner to u2;
ALTER PROPERTY GRAPH

CreatePropGraph() does not mention the reason behind this choice.
Should we remove this constraint and implement what the standard says?

If we allow any user to create a property graph containing elements
owned by other users per the standard, those users in turn may extend
their privileges to other users who do not have access to those
tables, if we don't implement security_invoker semantics. That's
another reason why behaviour as implemented in the patch.

I have added following comment in generate_query_for_graph_path()
/*
* Create RangeTblEntry for this element table.
*
* SQL/PGQ standard (Ref. Section 11.19, Access rule 2 and General rule
* 4) does not specify whose access privileges to use when accessing the
* element tables: property graph owner's or current user's. It is safer
* to use current user's privileges so as not to make property graphs as
* a hole for unpriviledged data access. This is inline with the views
* being security_invoker by default.
*/

The documentation of CREATE PROPERTY GRAPH already has
  <para>
   Access to the base relations underlying the <literal>GRAPH_TABLE</literal>
   clause is determined by the permissions of the user executing the query,
   rather than the property graph owner. Thus, the user of a property graph must
   have the relevant permissions on the property graph and base relations
   underlying the <literal>GRAPH_TABLE</literal> clause.
  </para>

Any other place which needs documentation?

>
> I think you could collapse all the patches into one patch now.  I have
> reviewed all the incremental patches and they all look ok to me.  I have
> made some notes about which things I want to review in more detail, such
> as the access control issue, but that doesn't need to be kept as a
> separate patch.
>

Ok. Attached only a single patch. I have consolidated the earlier
commit messages in the Notes section of the collapsed patch for future
reference. I don't think we need those detailed comments in the final
commit message. However, parts may be useful. We should also remove
WIP from the commit message subject line, but that can be done just
before commit.

> When you create future patches, consider using the git format-patch -v
> option.
>

I am still using timestamp as a version but passing it to -v instead
of treating it as a suffix. I like datestamp as versionstamp for the
reasons mentioned upthread.

> And then you can also just gzip the patch.  That should make it even
> smaller than the .zip file.
>

This time the total patch size seems to be below 1MB, so hopefully it
will not attract moderator's attention.

--
Best Wishes,
Ashutosh Bapat

  76. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-03T17:23:19Z

    On Tue, Dec 2, 2025 at 3:30 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> >
> > - I'm not so sure about the semantics chosen in the patch "Access
> > permissions on property graph".  I think according to the SQL standard,
> > once you have access to the property graph, you don't need access to the
> > underlying tables as well.  I guess you did this to align with how views
> > work?  We might need to think about this a bit more, and document
> > whatever the conclusion is.  But for now it's just small amount of code
> > affected.
>
> Section 7.1 Access rules seem to just require that the session user
> should have SELECT privileges on the property graph. I didn't find an
> answer to the question: What privileges should be used while accessing
> the element tables. Application of RLS policies depends upon the
> answer, for example. They  can be either the owner's privileges
> (security_definer semantics) or the privileges of session user
> (security_invoker semantics). A view can define what data it exposes
> precisely upto a row and column; hence a security_definer view can be
> made safer. But a property graph can not constrain rows that it
> exposes. So I feel, by default, security_invoker semantics are safer
> for property graphs. We may support security_definer semantics later,
> but it has to be an explicit choice by the user.

A view definition contains all the functions, operators and objects
which will be accessed when executing the view. However, when creating
a property graph, the user creating it, can not restrict the
functions, operators or other objects which will be used in the
GRAPH_TABLE clause. If we allow security_definer property graphs, a
malicious user can use it easily to escalate privileges. So, I think
supporting security_defined semantic on a property graph is very
dangerous. We should allow only security_invoker semantics.

-- 
Best Wishes,
Ashutosh Bapat

  77. Re: SQL Property Graph Queries (SQL/PGQ)

    amit <amitlangote09@gmail.com> — 2025-12-08T12:26:19Z

    On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> On Tue, Dec 2, 2025 at 3:30 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> > On Tue, Nov 25, 2025 at 7:22 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >
> > >
> > > - I'm not so sure about the semantics chosen in the patch "Access
> > > permissions on property graph".  I think according to the SQL standard,
> > > once you have access to the property graph, you don't need access to the
> > > underlying tables as well.  I guess you did this to align with how views
> > > work?  We might need to think about this a bit more, and document
> > > whatever the conclusion is.  But for now it's just small amount of code
> > > affected.
> >
> > Section 7.1 Access rules seem to just require that the session user
> > should have SELECT privileges on the property graph. I didn't find an
> > answer to the question: What privileges should be used while accessing
> > the element tables. Application of RLS policies depends upon the
> > answer, for example. They  can be either the owner's privileges
> > (security_definer semantics) or the privileges of session user
> > (security_invoker semantics). A view can define what data it exposes
> > precisely upto a row and column; hence a security_definer view can be
> > made safer. But a property graph can not constrain rows that it
> > exposes. So I feel, by default, security_invoker semantics are safer
> > for property graphs. We may support security_definer semantics later,
> > but it has to be an explicit choice by the user.
>
> A view definition contains all the functions, operators and objects
> which will be accessed when executing the view. However, when creating
> a property graph, the user creating it, can not restrict the
> functions, operators or other objects which will be used in the
> GRAPH_TABLE clause. If we allow security_definer property graphs, a
> malicious user can use it easily to escalate privileges. So, I think
> supporting security_defined semantic on a property graph is very
> dangerous. We should allow only security_invoker semantics.

+1 for invoker semantics as the default initially, and work on adding
a security-definer option if that’s needed in the future, which I
imagine might be trickier than what we have for views, not sure.

In your commit message:

4. We have not implemented security definer property graphs since
   SQL/PGQ standard does not mention those.

My reading of the access rules is that, from the caller’s point of
view, the standard expects behavior that is quite close to
security-definer semantics -- once the session user has SELECT on the
property graph, they do not need privileges on the element tables. Is
that also how you read it, or do you see the standard as intentionally
leaving room for invoker semantics like you've currently implemented?

--
Thanks, Amit Langote

  78. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-08T14:58:59Z

    On Mon, Dec 8, 2025 at 5:56 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Dec 4, 2025 at 2:23 AM Ashutosh Bapat
>
> In your commit message:
>
> 4. We have not implemented security definer property graphs since
>    SQL/PGQ standard does not mention those.
>
> My reading of the access rules is that, from the caller’s point of
> view, the standard expects behavior that is quite close to
> security-definer semantics -- once the session user has SELECT on the
> property graph, they do not need privileges on the element tables. Is
> that also how you read it, or do you see the standard as intentionally
> leaving room for invoker semantics like you've currently implemented?
>

The standard specifies that in order to reference a property graph in
the query, the query invoker has to have SELECT privileges on the
property graph. I am not able to find a specification which answers:
who's privileges should be used to access the underlying tables. So I
can't say whether it's close to security-definer semantics or not. I
also can not infer any intent. But as I have explained above,
security-definer semantics seem to be too dangerous to implement. But
may be there's some other safe interpretation of standard
specification, which I am missing.

-- 
Best Wishes,
Ashutosh Bapat

  79. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-08T15:53:58Z

    On 02.12.25 11:00, Ashutosh Bapat wrote:
>> When you create future patches, consider using the git format-patch -v
>> option.
>>
> I am still using timestamp as a version but passing it to -v instead
> of treating it as a suffix. I like datestamp as versionstamp for the
> reasons mentioned upthread.

Date stamps are great, but why is there a hyphen between the "v" and the 
number?

I have committed the parse.pl patch, mainly to test it out so that we 
don't have surprises later.  (I had problems in the past making it work 
with older Perl versions, but things seems to have shifted forward now.) 
  It can live on its own, I think.

It looks like undirected matching -[ ]- (without arrows) doesn't work 
correctly.  It seems to just match in one direction.  I don't see any 
tests.  Is this implemented?

Also, make sure the role names in graph_table_rls.sql start with regress_:

  CREATE USER graph_rls_alice NOLOGIN;
+WARNING:  roles created by regression test cases should have names 
starting with "regress_"

(This is the FreeBSD CI failure.)

  80. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-09T10:21:16Z

    On Mon, Dec 8, 2025 at 9:24 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 02.12.25 11:00, Ashutosh Bapat wrote:
> >> When you create future patches, consider using the git format-patch -v
> >> option.
> >>
> > I am still using timestamp as a version but passing it to -v instead
> > of treating it as a suffix. I like datestamp as versionstamp for the
> > reasons mentioned upthread.
>
> Date stamps are great, but why is there a hyphen between the "v" and the
> number?

I was using -v=<version number> instead of -v <version number>. Fixed.

>
> I have committed the parse.pl patch, mainly to test it out so that we
> don't have surprises later.  (I had problems in the past making it work
> with older Perl versions, but things seems to have shifted forward now.)
>   It can live on its own, I think.

+1. Buildfarm seems to be happy with the change.

>
> It looks like undirected matching -[ ]- (without arrows) doesn't work
> correctly.  It seems to just match in one direction.  I don't see any
> tests.  Is this implemented?
>

-[]- is called full edge any direction
<full edge any direction> ::=
<minus left bracket> <element pattern filler> <right bracket minus>

~[]~ is defined as full edge undirected
<full edge undirected> ::=
<tilde left bracket> <element pattern filler> <right bracket tilde>

The patch supports full edge any direction since [1] in response to
Ajay Pal's report. Such a pattern matches edges in both the
directions. There's also a test
-- edges directed in both ways - to and from v2
SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-[conn]-(v2) COLUMNS
(v1.vname AS v1name, conn.ename AS cname, v2.vname AS v2name));
 v1name | cname | v2name
--------+-------+--------
 v21    | e122  | v12
 v22    | e121  | v11
 v22    | e231  | v32
(3 rows)

SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-(v2) COLUMNS (v1.vname
AS v1name, v2.vname AS v2name));
 v1name | v2name
--------+--------
 v21    | v12
 v22    | v11
 v22    | v32
(3 rows)

it's matching edges to and from vertices in v2. For example e121 is an
edge from v11 to v22 whereas e231 is an edge from v22 to v32.

We do not support full edge undirected. gram.y doesn't have grammar
for the same. In fact, I don't think we have a way to specify
undirected edges in the property graph DDL itself. Do you think we
should implement ~[ ] ~?

> Also, make sure the role names in graph_table_rls.sql start with regress_:
>
>   CREATE USER graph_rls_alice NOLOGIN;
> +WARNING:  roles created by regression test cases should have names
> starting with "regress_"
>
> (This is the FreeBSD CI failure.)
>

Thanks for pointing that out. I can reproduce the failure on my
laptop. Fixed in the attached patch. I have used regress_graph_rls_ as
a user or role name prefix. It's a bit long but I see other tests also
using longer names regress_file_fdw_superuser. If we want a shorter
name we could use regress_pg_rls (pg: for property graph) but that can
be easily confused with PostgreSQL.

[1] https://www.postgresql.org/message-id/CAExHW5vqo7iTcVznspb3HHD87Ps3Q%3DJF6_gg%2Bh5mhyuwhd3Q4Q%40mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

  81. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-13T19:57:56Z

    On 09.12.25 11:21, Ashutosh Bapat wrote:
>> It looks like undirected matching -[ ]- (without arrows) doesn't work
>> correctly.  It seems to just match in one direction.  I don't see any
>> tests.  Is this implemented?
>>
> -[]- is called full edge any direction
> <full edge any direction> ::=
> <minus left bracket> <element pattern filler> <right bracket minus>
> 
> ~[]~ is defined as full edge undirected
> <full edge undirected> ::=
> <tilde left bracket> <element pattern filler> <right bracket tilde>
> 
> The patch supports full edge any direction since [1] in response to
> Ajay Pal's report. Such a pattern matches edges in both the
> directions. There's also a test
> -- edges directed in both ways - to and from v2
> SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-[conn]-(v2) COLUMNS
> (v1.vname AS v1name, conn.ename AS cname, v2.vname AS v2name));
>   v1name | cname | v2name
> --------+-------+--------
>   v21    | e122  | v12
>   v22    | e121  | v11
>   v22    | e231  | v32
> (3 rows)
> 
> SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-(v2) COLUMNS (v1.vname
> AS v1name, v2.vname AS v2name));
>   v1name | v2name
> --------+--------
>   v21    | v12
>   v22    | v11
>   v22    | v32
> (3 rows)
> 
> it's matching edges to and from vertices in v2. For example e121 is an
> edge from v11 to v22 whereas e231 is an edge from v22 to v32.

Attached is a test case from an Oracle web site (the URL is in the 
file).  At the end there are three queries, one left, one right, one any 
direction.  The latter should result in the union of the first two, but 
it doesn't.

  82. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-15T13:13:08Z

    On Sun, Dec 14, 2025 at 1:28 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 09.12.25 11:21, Ashutosh Bapat wrote:
> >> It looks like undirected matching -[ ]- (without arrows) doesn't work
> >> correctly.  It seems to just match in one direction.  I don't see any
> >> tests.  Is this implemented?
> >>
> > -[]- is called full edge any direction
> > <full edge any direction> ::=
> > <minus left bracket> <element pattern filler> <right bracket minus>
> >
> > ~[]~ is defined as full edge undirected
> > <full edge undirected> ::=
> > <tilde left bracket> <element pattern filler> <right bracket tilde>
> >
> > The patch supports full edge any direction since [1] in response to
> > Ajay Pal's report. Such a pattern matches edges in both the
> > directions. There's also a test
> > -- edges directed in both ways - to and from v2
> > SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-[conn]-(v2) COLUMNS
> > (v1.vname AS v1name, conn.ename AS cname, v2.vname AS v2name));
> >   v1name | cname | v2name
> > --------+-------+--------
> >   v21    | e122  | v12
> >   v22    | e121  | v11
> >   v22    | e231  | v32
> > (3 rows)
> >
> > SELECT * FROM GRAPH_TABLE (g1 MATCH (v1 IS vl2)-(v2) COLUMNS (v1.vname
> > AS v1name, v2.vname AS v2name));
> >   v1name | v2name
> > --------+--------
> >   v21    | v12
> >   v22    | v11
> >   v22    | v32
> > (3 rows)
> >
> > it's matching edges to and from vertices in v2. For example e121 is an
> > edge from v11 to v22 whereas e231 is an edge from v22 to v32.
>
> Attached is a test case from an Oracle web site (the URL is in the
> file).  At the end there are three queries, one left, one right, one any
> direction.  The latter should result in the union of the first two, but
> it doesn't.

Thanks for the example. I see it now. The code, in previous patch,
works when the vertices adjacent to an edge come from different
tables. In such a case only right or left direction is possible. When
the adjacent vertices of an edge come from the same table edge can be
from left or right and we need to match both the directions. The edge
link quals should have conditions for edges in both directions
connected by OR. Done that way in the attached patch. Also added a few
more queries containing edges in any direction.

I also noticed the following mistakes in the patch and fixed those.
1. e3_3 entry for property graph g1 in graph_table.sql was using the
same column as both source and destination key. Fixed that to use
appropriate columns.
2. When GRAPH_TABLE has no conditions whatsoever, e.g. GRAPH_TABLE (g1
MATCH () COLUMNS (1)), generate_query_for_graph_path() constructed a
bool expression representing NIL quals. This does not cause a problem
since somewhere down the line, a bool expression without any clause is
appropriately replaced with true or false. However, it crashed when
passed through pg_get_querydef() since get_rule_expr() calls linitial
on expr->args without checking for NIL-ness. Fixed the construction of
bool expression in generate_query_for_graph_path().

rewriteGraphTable() has following code
#if 0
elog(INFO, "rewritten:\n%s", pg_get_querydef(copyObject(parsetree), false));
#endif
Do we want to remove it or keep it with some note or under #ifdef
DEBUG_GRAPH_TABLE_REWRITE or some such? I am mildly leaning towards
keeping it under the #ifdef, but not a whole lot. Anybody who wants to
debug can add that single line, if they want.

I have added the fixes as a separate 0002 patch. Once reviewed I will
squash it into 0001 in the next round.

Rebased patches on the latest HEAD which required me to move
graph_table.sql to another parallel group.

-- 
Best Wishes,
Ashutosh Bapat

  83. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-17T05:32:30Z

    On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> 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.

-- 
Best Wishes,
Ashutosh Bapat

  84. Re: SQL Property Graph Queries (SQL/PGQ)

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-17T08:58:22Z

    On 17.12.25 06:32, Ashutosh Bapat wrote:
> On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> 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.

  85. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-18T09:15:29Z

    On Wed, Dec 17, 2025 at 2:28 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 17.12.25 06:32, Ashutosh Bapat wrote:
> > On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> 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.

+1. The error message is better.

>
> 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.

+1.

Attached patch adds a couple more test statements.

>
> 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.
>

I was aware of ecpg and I vaguely remember we fixed something in ECPG
to allow : in MATCH statement. Probably following changes in
psqlscan.l and pgc.l
-self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
+self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]

Those changes add | after : (and not the : itself) so maybe they are
not about supporting : . Do you remember what those are?

However, I see that : in psql can be a problem
#create table t1 (a int, b int);
#create property graph g1 vertex tables (t1 key (a));
#select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
 a
---
(0 rows)

#\set t1 blank
#select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
ERROR:  syntax error at or near "blank"
LINE 1: select * from GRAPH_TABLE (g1 MATCH (a blank) COLUMNS (a.a))...

> 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.)
>

That might have been just me trying to type one letter less and yet
keeping the query readable. A column between variable name and the
label is not always noticeable.

> 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.

I agree that it's better not to support it now. It requires more work
and it's optional. When we come to support it, we will need thorough
testing.

I spotted some examples that use : in ddl.sgml.
<programlisting>
SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
(c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
COLUMNS (c.name AS customer_name));
</programlisting>

The query demonstrates that one can use label names in a way that will
make the pattern look like an English sentence. Replacing : with IS
defeats that purpose.

As written in that paragraph, the labels serve the purpose of exposing
the table with a different logical view (using different label and
property names). So we need that paragraph, but I think we should
change the example to use IS instead of :. Attached is suggested
minimal change, but I am not happy with it. Another possibility is we
completely remove that paragraph; I don't think we need to discuss all
possible usages the users will come up with.

The patch changes one more instance of : by IS. But that's straight forward.

In ddl.sgml I noticed a seemingly incomplete sentence
   A property graph is a way to represent database contents, instead of using
   relational structures such as tables.

Represent the contents as what? I feel the complete sentence should be
one of the following
property graph is a way to represent database contents as a graph,
instead of representing those as relational structures OR
property graph is another way to represent database contents instead
of using relational structures such as tables

But I can't figure out what was originally intended.

I have squashed 0002 from my earlier patchset and your 3 patches into 0001.

0002 has extra tests mentioned above. It also removes "TODO: dubious
error message" from a comment. I don't see anything dubious in the
error message. I think this patch is safe to be merged into 0001.

0003 is changed to ddl.sgml. Those need a bit more work as described above.

-- 
Best Wishes,
Ashutosh Bapat

  86. Re: SQL Property Graph Queries (SQL/PGQ)

    Henson Choi <assam258@gmail.com> — 2025-12-24T16:23:11Z

    Subject: Re: SQL Property Graph Queries (SQL/PGQ)

Hi hackers,

Apologies for jumping into the SQL/PGQ discussion mid-stream. I've been
working on implementing the LABELS() graph element function and ran into
an issue I'd like to get some guidance on.

== What LABELS() does ==

LABELS(element_variable) returns a text[] array containing all labels
associated with a graph element. For example:

  SELECT * FROM GRAPH_TABLE (myshop
      MATCH (n IS customers)
      COLUMNS (n.name, LABELS(n) AS lbls)
  );

     name     |    lbls
  ------------+-------------
   customer1  | {customers}
   customer2  | {customers}

== Implementation approach ==

A naive approach would return LABELS() as a constant (e.g.,
ARRAY['customers']
directly). However, this prevents the optimizer from pushing down predicates
involving LABELS() through UNION ALL branches.

To enable optimizer pushdown, I wrap each element table in a subquery that
adds a virtual __labels__ column containing a constant array. This way,
LABELS(n) returns a Var referencing that column, allowing the optimizer to
evaluate it per-branch and prune accordingly:

  -- Conceptually, the rewrite produces:
  SELECT name, __labels__ AS lbls FROM (
      SELECT *, ARRAY['customers']::text[] AS __labels__ FROM customers
  ) ...

This allows the optimizer to perform constant folding and prune UNION ALL
branches when filtering by label:

  -- Filter in outer WHERE clause
  EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
      MATCH (n IS lists)  -- lists label shared by orders and wishlists
      COLUMNS (LABELS(n) AS lbls, n.node_id)
  ) WHERE 'orders' = ANY(lbls);

                       QUERY PLAN
  ------------------------------------------------------
   Seq Scan on orders
     Output: '{orders,lists}'::text[], orders.order_id

  -- Filter in MATCH WHERE clause without IS (both tables scanned)
  EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
      MATCH (n) WHERE 'lists' = ANY(LABELS(n))
      COLUMNS (LABELS(n) AS lbls, n.node_id)
  );

                       QUERY PLAN
  ------------------------------------------------------
   Append
     ->  Seq Scan on orders
           Output: '{orders,lists}'::text[], orders.order_id
     ->  Seq Scan on wishlists
           Output: '{lists,wishlists}'::text[], wishlists.wishlist_id

The first example prunes the wishlists branch since 'orders' is not in its
label set. The second example uses LABELS() without an IS clause to filter
across all element tables that have the 'lists' label.

== The problem ==

The subquery wrapping breaks column-level privilege checking.

Test case from privileges.sql:

  -- regress_priv_user4 has SELECT on atest5(one, four) only
  -- lttc label maps atest5.three -> lttck (no privilege)

  SET ROLE regress_priv_user4;
  SELECT * FROM graph_table (ptg1 MATCH (v IS lttc) COLUMNS (v.lttck));
  -- Expected: ERROR: permission denied for table atest5
  -- Actual: query succeeds (returns rows without error)

I haven't yet identified the exact root cause of this issue. Has anyone
encountered a similar issue? Any pointers would be appreciated.

Thanks,
Henson

2025년 12월 18일 (목) PM 6:16, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>님이
작성:

> On Wed, Dec 17, 2025 at 2:28 PM Peter Eisentraut <peter@eisentraut.org>
> wrote:
> >
> > On 17.12.25 06:32, Ashutosh Bapat wrote:
> > > On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
> > > <ashutosh.bapat.oss@gmail.com> 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.
>
> +1. The error message is better.
>
> >
> > 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.
>
> +1.
>
> Attached patch adds a couple more test statements.
>
> >
> > 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.
> >
>
> I was aware of ecpg and I vaguely remember we fixed something in ECPG
> to allow : in MATCH statement. Probably following changes in
> psqlscan.l and pgc.l
> -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
> +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
>
> Those changes add | after : (and not the : itself) so maybe they are
> not about supporting : . Do you remember what those are?
>
> However, I see that : in psql can be a problem
> #create table t1 (a int, b int);
> #create property graph g1 vertex tables (t1 key (a));
> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
>  a
> ---
> (0 rows)
>
> #\set t1 blank
> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
> ERROR:  syntax error at or near "blank"
> LINE 1: select * from GRAPH_TABLE (g1 MATCH (a blank) COLUMNS (a.a))...
>
> > 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.)
> >
>
> That might have been just me trying to type one letter less and yet
> keeping the query readable. A column between variable name and the
> label is not always noticeable.
>
> > 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.
>
> I agree that it's better not to support it now. It requires more work
> and it's optional. When we come to support it, we will need thorough
> testing.
>
> I spotted some examples that use : in ddl.sgml.
> <programlisting>
> SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
> (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
> COLUMNS (c.name AS customer_name));
> </programlisting>
>
> The query demonstrates that one can use label names in a way that will
> make the pattern look like an English sentence. Replacing : with IS
> defeats that purpose.
>
> As written in that paragraph, the labels serve the purpose of exposing
> the table with a different logical view (using different label and
> property names). So we need that paragraph, but I think we should
> change the example to use IS instead of :. Attached is suggested
> minimal change, but I am not happy with it. Another possibility is we
> completely remove that paragraph; I don't think we need to discuss all
> possible usages the users will come up with.
>
> The patch changes one more instance of : by IS. But that's straight
> forward.
>
> In ddl.sgml I noticed a seemingly incomplete sentence
>    A property graph is a way to represent database contents, instead of
> using
>    relational structures such as tables.
>
> Represent the contents as what? I feel the complete sentence should be
> one of the following
> property graph is a way to represent database contents as a graph,
> instead of representing those as relational structures OR
> property graph is another way to represent database contents instead
> of using relational structures such as tables
>
> But I can't figure out what was originally intended.
>
> I have squashed 0002 from my earlier patchset and your 3 patches into 0001.
>
> 0002 has extra tests mentioned above. It also removes "TODO: dubious
> error message" from a comment. I don't see anything dubious in the
> error message. I think this patch is safe to be merged into 0001.
>
> 0003 is changed to ddl.sgml. Those need a bit more work as described above.
>
> --
> Best Wishes,
> Ashutosh Bapat
>

  87. Re: SQL Property Graph Queries (SQL/PGQ)

    Henson Choi <assam258@gmail.com> — 2025-12-26T12:33:41Z

    Following up on my Dec 24 email - three features completed:

1. LABELS() function
   - Returns text[] of element labels
   - Fixed privilege checking from previous version
   - Enables optimizer pushdown for branch pruning

2. PROPERTY_NAMES() function
   - Returns text[] of property names
   - Similar approach to LABELS()

3. Multiple path patterns
   - Syntax: MATCH (a)->(b), (b)->(c)
   - Implements SQL/PGQ standard feature (was TODO)

Patches attached.

Best regards,
Henson Choi

---
Background: Currently at Inzent (PostgreSQL-based TDE). Previously
at AgensGraph (PostgreSQL-based graph DB, 2017-2020).

2025년 12월 25일 (목) AM 1:23, Henson Choi <assam258@gmail.com>님이 작성:

> Subject: Re: SQL Property Graph Queries (SQL/PGQ)
>
> Hi hackers,
>
> Apologies for jumping into the SQL/PGQ discussion mid-stream. I've been
> working on implementing the LABELS() graph element function and ran into
> an issue I'd like to get some guidance on.
>
> == What LABELS() does ==
>
> LABELS(element_variable) returns a text[] array containing all labels
> associated with a graph element. For example:
>
>   SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n IS customers)
>       COLUMNS (n.name, LABELS(n) AS lbls)
>   );
>
>      name     |    lbls
>   ------------+-------------
>    customer1  | {customers}
>    customer2  | {customers}
>
> == Implementation approach ==
>
> A naive approach would return LABELS() as a constant (e.g.,
> ARRAY['customers']
> directly). However, this prevents the optimizer from pushing down
> predicates
> involving LABELS() through UNION ALL branches.
>
> To enable optimizer pushdown, I wrap each element table in a subquery that
> adds a virtual __labels__ column containing a constant array. This way,
> LABELS(n) returns a Var referencing that column, allowing the optimizer to
> evaluate it per-branch and prune accordingly:
>
>   -- Conceptually, the rewrite produces:
>   SELECT name, __labels__ AS lbls FROM (
>       SELECT *, ARRAY['customers']::text[] AS __labels__ FROM customers
>   ) ...
>
> This allows the optimizer to perform constant folding and prune UNION ALL
> branches when filtering by label:
>
>   -- Filter in outer WHERE clause
>   EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n IS lists)  -- lists label shared by orders and wishlists
>       COLUMNS (LABELS(n) AS lbls, n.node_id)
>   ) WHERE 'orders' = ANY(lbls);
>
>                        QUERY PLAN
>   ------------------------------------------------------
>    Seq Scan on orders
>      Output: '{orders,lists}'::text[], orders.order_id
>
>   -- Filter in MATCH WHERE clause without IS (both tables scanned)
>   EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n) WHERE 'lists' = ANY(LABELS(n))
>       COLUMNS (LABELS(n) AS lbls, n.node_id)
>   );
>
>                        QUERY PLAN
>   ------------------------------------------------------
>    Append
>      ->  Seq Scan on orders
>            Output: '{orders,lists}'::text[], orders.order_id
>      ->  Seq Scan on wishlists
>            Output: '{lists,wishlists}'::text[], wishlists.wishlist_id
>
> The first example prunes the wishlists branch since 'orders' is not in its
> label set. The second example uses LABELS() without an IS clause to filter
> across all element tables that have the 'lists' label.
>
> == The problem ==
>
> The subquery wrapping breaks column-level privilege checking.
>
> Test case from privileges.sql:
>
>   -- regress_priv_user4 has SELECT on atest5(one, four) only
>   -- lttc label maps atest5.three -> lttck (no privilege)
>
>   SET ROLE regress_priv_user4;
>   SELECT * FROM graph_table (ptg1 MATCH (v IS lttc) COLUMNS (v.lttck));
>   -- Expected: ERROR: permission denied for table atest5
>   -- Actual: query succeeds (returns rows without error)
>
> I haven't yet identified the exact root cause of this issue. Has anyone
> encountered a similar issue? Any pointers would be appreciated.
>
> Thanks,
> Henson
>
> 2025년 12월 18일 (목) PM 6:16, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>님이
> 작성:
>
>> On Wed, Dec 17, 2025 at 2:28 PM Peter Eisentraut <peter@eisentraut.org>
>> wrote:
>> >
>> > On 17.12.25 06:32, Ashutosh Bapat wrote:
>> > > On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
>> > > <ashutosh.bapat.oss@gmail.com> 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.
>>
>> +1. The error message is better.
>>
>> >
>> > 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.
>>
>> +1.
>>
>> Attached patch adds a couple more test statements.
>>
>> >
>> > 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.
>> >
>>
>> I was aware of ecpg and I vaguely remember we fixed something in ECPG
>> to allow : in MATCH statement. Probably following changes in
>> psqlscan.l and pgc.l
>> -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
>> +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
>>
>> Those changes add | after : (and not the : itself) so maybe they are
>> not about supporting : . Do you remember what those are?
>>
>> However, I see that : in psql can be a problem
>> #create table t1 (a int, b int);
>> #create property graph g1 vertex tables (t1 key (a));
>> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
>>  a
>> ---
>> (0 rows)
>>
>> #\set t1 blank
>> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
>> ERROR:  syntax error at or near "blank"
>> LINE 1: select * from GRAPH_TABLE (g1 MATCH (a blank) COLUMNS (a.a))...
>>
>> > 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.)
>> >
>>
>> That might have been just me trying to type one letter less and yet
>> keeping the query readable. A column between variable name and the
>> label is not always noticeable.
>>
>> > 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.
>>
>> I agree that it's better not to support it now. It requires more work
>> and it's optional. When we come to support it, we will need thorough
>> testing.
>>
>> I spotted some examples that use : in ddl.sgml.
>> <programlisting>
>> SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
>> (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
>> COLUMNS (c.name AS customer_name));
>> </programlisting>
>>
>> The query demonstrates that one can use label names in a way that will
>> make the pattern look like an English sentence. Replacing : with IS
>> defeats that purpose.
>>
>> As written in that paragraph, the labels serve the purpose of exposing
>> the table with a different logical view (using different label and
>> property names). So we need that paragraph, but I think we should
>> change the example to use IS instead of :. Attached is suggested
>> minimal change, but I am not happy with it. Another possibility is we
>> completely remove that paragraph; I don't think we need to discuss all
>> possible usages the users will come up with.
>>
>> The patch changes one more instance of : by IS. But that's straight
>> forward.
>>
>> In ddl.sgml I noticed a seemingly incomplete sentence
>>    A property graph is a way to represent database contents, instead of
>> using
>>    relational structures such as tables.
>>
>> Represent the contents as what? I feel the complete sentence should be
>> one of the following
>> property graph is a way to represent database contents as a graph,
>> instead of representing those as relational structures OR
>> property graph is another way to represent database contents instead
>> of using relational structures such as tables
>>
>> But I can't figure out what was originally intended.
>>
>> I have squashed 0002 from my earlier patchset and your 3 patches into
>> 0001.
>>
>> 0002 has extra tests mentioned above. It also removes "TODO: dubious
>> error message" from a comment. I don't see anything dubious in the
>> error message. I think this patch is safe to be merged into 0001.
>>
>> 0003 is changed to ddl.sgml. Those need a bit more work as described
>> above.
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>>
>

  88. Re: SQL Property Graph Queries (SQL/PGQ)

    Henson Choi <assam258@gmail.com> — 2025-12-28T04:43:54Z

    Hi,

I apologize for the confusion caused by my partial patch submission.
The patch was intended to be applied on top of the PGQ base patch,
but I was not aware that CFBot would try to apply it directly to master.

Next time, I will use a .txt extension so that the original authors
can review it before CFBot processes it.

Sorry for the inconvenience.

Regards,
Henson Choi

2025년 12월 25일 (목) AM 1:23, Henson Choi <assam258@gmail.com>님이 작성:

> Subject: Re: SQL Property Graph Queries (SQL/PGQ)
>
> Hi hackers,
>
> Apologies for jumping into the SQL/PGQ discussion mid-stream. I've been
> working on implementing the LABELS() graph element function and ran into
> an issue I'd like to get some guidance on.
>
> == What LABELS() does ==
>
> LABELS(element_variable) returns a text[] array containing all labels
> associated with a graph element. For example:
>
>   SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n IS customers)
>       COLUMNS (n.name, LABELS(n) AS lbls)
>   );
>
>      name     |    lbls
>   ------------+-------------
>    customer1  | {customers}
>    customer2  | {customers}
>
> == Implementation approach ==
>
> A naive approach would return LABELS() as a constant (e.g.,
> ARRAY['customers']
> directly). However, this prevents the optimizer from pushing down
> predicates
> involving LABELS() through UNION ALL branches.
>
> To enable optimizer pushdown, I wrap each element table in a subquery that
> adds a virtual __labels__ column containing a constant array. This way,
> LABELS(n) returns a Var referencing that column, allowing the optimizer to
> evaluate it per-branch and prune accordingly:
>
>   -- Conceptually, the rewrite produces:
>   SELECT name, __labels__ AS lbls FROM (
>       SELECT *, ARRAY['customers']::text[] AS __labels__ FROM customers
>   ) ...
>
> This allows the optimizer to perform constant folding and prune UNION ALL
> branches when filtering by label:
>
>   -- Filter in outer WHERE clause
>   EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n IS lists)  -- lists label shared by orders and wishlists
>       COLUMNS (LABELS(n) AS lbls, n.node_id)
>   ) WHERE 'orders' = ANY(lbls);
>
>                        QUERY PLAN
>   ------------------------------------------------------
>    Seq Scan on orders
>      Output: '{orders,lists}'::text[], orders.order_id
>
>   -- Filter in MATCH WHERE clause without IS (both tables scanned)
>   EXPLAIN SELECT * FROM GRAPH_TABLE (myshop
>       MATCH (n) WHERE 'lists' = ANY(LABELS(n))
>       COLUMNS (LABELS(n) AS lbls, n.node_id)
>   );
>
>                        QUERY PLAN
>   ------------------------------------------------------
>    Append
>      ->  Seq Scan on orders
>            Output: '{orders,lists}'::text[], orders.order_id
>      ->  Seq Scan on wishlists
>            Output: '{lists,wishlists}'::text[], wishlists.wishlist_id
>
> The first example prunes the wishlists branch since 'orders' is not in its
> label set. The second example uses LABELS() without an IS clause to filter
> across all element tables that have the 'lists' label.
>
> == The problem ==
>
> The subquery wrapping breaks column-level privilege checking.
>
> Test case from privileges.sql:
>
>   -- regress_priv_user4 has SELECT on atest5(one, four) only
>   -- lttc label maps atest5.three -> lttck (no privilege)
>
>   SET ROLE regress_priv_user4;
>   SELECT * FROM graph_table (ptg1 MATCH (v IS lttc) COLUMNS (v.lttck));
>   -- Expected: ERROR: permission denied for table atest5
>   -- Actual: query succeeds (returns rows without error)
>
> I haven't yet identified the exact root cause of this issue. Has anyone
> encountered a similar issue? Any pointers would be appreciated.
>
> Thanks,
> Henson
>
> 2025년 12월 18일 (목) PM 6:16, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>님이
> 작성:
>
>> On Wed, Dec 17, 2025 at 2:28 PM Peter Eisentraut <peter@eisentraut.org>
>> wrote:
>> >
>> > On 17.12.25 06:32, Ashutosh Bapat wrote:
>> > > On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
>> > > <ashutosh.bapat.oss@gmail.com> 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.
>>
>> +1. The error message is better.
>>
>> >
>> > 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.
>>
>> +1.
>>
>> Attached patch adds a couple more test statements.
>>
>> >
>> > 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.
>> >
>>
>> I was aware of ecpg and I vaguely remember we fixed something in ECPG
>> to allow : in MATCH statement. Probably following changes in
>> psqlscan.l and pgc.l
>> -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
>> +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
>>
>> Those changes add | after : (and not the : itself) so maybe they are
>> not about supporting : . Do you remember what those are?
>>
>> However, I see that : in psql can be a problem
>> #create table t1 (a int, b int);
>> #create property graph g1 vertex tables (t1 key (a));
>> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
>>  a
>> ---
>> (0 rows)
>>
>> #\set t1 blank
>> #select * from GRAPH_TABLE (g1 MATCH (a :t1) COLUMNS (a.a));
>> ERROR:  syntax error at or near "blank"
>> LINE 1: select * from GRAPH_TABLE (g1 MATCH (a blank) COLUMNS (a.a))...
>>
>> > 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.)
>> >
>>
>> That might have been just me trying to type one letter less and yet
>> keeping the query readable. A column between variable name and the
>> label is not always noticeable.
>>
>> > 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.
>>
>> I agree that it's better not to support it now. It requires more work
>> and it's optional. When we come to support it, we will need thorough
>> testing.
>>
>> I spotted some examples that use : in ddl.sgml.
>> <programlisting>
>> SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
>> (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
>> COLUMNS (c.name AS customer_name));
>> </programlisting>
>>
>> The query demonstrates that one can use label names in a way that will
>> make the pattern look like an English sentence. Replacing : with IS
>> defeats that purpose.
>>
>> As written in that paragraph, the labels serve the purpose of exposing
>> the table with a different logical view (using different label and
>> property names). So we need that paragraph, but I think we should
>> change the example to use IS instead of :. Attached is suggested
>> minimal change, but I am not happy with it. Another possibility is we
>> completely remove that paragraph; I don't think we need to discuss all
>> possible usages the users will come up with.
>>
>> The patch changes one more instance of : by IS. But that's straight
>> forward.
>>
>> In ddl.sgml I noticed a seemingly incomplete sentence
>>    A property graph is a way to represent database contents, instead of
>> using
>>    relational structures such as tables.
>>
>> Represent the contents as what? I feel the complete sentence should be
>> one of the following
>> property graph is a way to represent database contents as a graph,
>> instead of representing those as relational structures OR
>> property graph is another way to represent database contents instead
>> of using relational structures such as tables
>>
>> But I can't figure out what was originally intended.
>>
>> I have squashed 0002 from my earlier patchset and your 3 patches into
>> 0001.
>>
>> 0002 has extra tests mentioned above. It also removes "TODO: dubious
>> error message" from a comment. I don't see anything dubious in the
>> error message. I think this patch is safe to be merged into 0001.
>>
>> 0003 is changed to ddl.sgml. Those need a bit more work as described
>> above.
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>>
>

  89. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-30T09:44:02Z

    On Thu, Dec 18, 2025 at 2:45 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
>
> >
> > 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.
>
> +1.
>
> Attached patch adds a couple more test statements.
>

Squashed this into the main patchset.

> >
> > 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.
> >
>
> I was aware of ecpg and I vaguely remember we fixed something in ECPG
> to allow : in MATCH statement. Probably following changes in
> psqlscan.l and pgc.l
> -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
> +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
>
> Those changes add | after : (and not the : itself) so maybe they are
> not about supporting : . Do you remember what those are?

I reverted those changes from both the files and ran "meson test". I
did not observe any failure. It seems those changes are not needed.
But adding them as a separate commit (0004) in case CI bot reveals any
failures without them.

I noticed that there were no ECPG tests for SQL/PGQ. Added a basic
test in patch 0003.

>
> I spotted some examples that use : in ddl.sgml.
> <programlisting>
> SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
> (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
> COLUMNS (c.name AS customer_name));
> </programlisting>
>
> The query demonstrates that one can use label names in a way that will
> make the pattern look like an English sentence. Replacing : with IS
> defeats that purpose.
>
> As written in that paragraph, the labels serve the purpose of exposing
> the table with a different logical view (using different label and
> property names). So we need that paragraph, but I think we should
> change the example to use IS instead of :. Attached is suggested
> minimal change, but I am not happy with it. Another possibility is we
> completely remove that paragraph; I don't think we need to discuss all
> possible usages the users will come up with.
>
> The patch changes one more instance of : by IS. But that's straight forward.
>
> In ddl.sgml I noticed a seemingly incomplete sentence
>    A property graph is a way to represent database contents, instead of using
>    relational structures such as tables.
>
> Represent the contents as what? I feel the complete sentence should be
> one of the following
> property graph is a way to represent database contents as a graph,
> instead of representing those as relational structures OR
> property graph is another way to represent database contents instead
> of using relational structures such as tables
>
> But I can't figure out what was originally intended.


0002 contains some edits to this part of documentation. I think the
paragraph reads better than before. Let me know what you think.

Please let me know which of 0002 to 0004 look good to you. I will
squash those into the patchset in the next version.

-- 
Best Wishes,
Ashutosh Bapat

  90. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-30T09:50:09Z

    Hi Henson,

Thanks a lot for your interest in SQL/PGQ patches. Your expertise will
certainly help.

On Fri, Dec 26, 2025 at 6:03 PM Henson Choi <assam258@gmail.com> wrote:
>
> Following up on my Dec 24 email - three features completed:
>
> 1. LABELS() function
>    - Returns text[] of element labels
>    - Fixed privilege checking from previous version
>    - Enables optimizer pushdown for branch pruning
>
> 2. PROPERTY_NAMES() function
>    - Returns text[] of property names
>    - Similar approach to LABELS()
>

I could not find specification of these functions in SQL/PGQ standard.
It's a large document and I might be missing something. Can you please
point me to the relevant sections?

> 3. Multiple path patterns
>    - Syntax: MATCH (a)->(b), (b)->(c)
>    - Implements SQL/PGQ standard feature (was TODO)
>

This path pattern list feature is discussed in section 10.4 of the
standard. I think supporting this feature would be a good addition to
SQL/PGQ compliance. The current patchset is already large. I (and
AFAIK Peter as well) am focusing on getting that patchset in a
committable shape. Once committed, it will facilitate adding features
like path pattern list, quantified path patterns, label conjunction
etc. as incremental relatively smaller commits.

Since you could build one of the complex features without changing a
lot of earlier implementation, it validates that the basic
implementation is extensible and yet robust. Thanks for that
validation.

The way you have implemented it, it can lead to a path pattern with
two vertex patterns next to each other without an interleaving edge
pattern. That would throw an error or assertion. If you try path
patterns without a common vertex, you will get that error. That is not
covered by your tests. In such cases, the paths should end up being
full-joined rather than concatenated. I don't see it being implemented
that way. I think more work is needed here.

[1] https://www.postgresql.org/message-id/CAExHW5sr+dJPCFw2OqXUfPPqPks8qmsivaAYhRiBdFANcX8RHw@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

  91. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-30T11:27:15Z

    On Tue, Dec 30, 2025 at 3:14 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Thu, Dec 18, 2025 at 2:45 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> >
> > >
> > > 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.
> >
> > +1.
> >
> > Attached patch adds a couple more test statements.
> >
>
> Squashed this into the main patchset.
>
> > >
> > > 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.
> > >
> >
> > I was aware of ecpg and I vaguely remember we fixed something in ECPG
> > to allow : in MATCH statement. Probably following changes in
> > psqlscan.l and pgc.l
> > -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
> > +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
> >
> > Those changes add | after : (and not the : itself) so maybe they are
> > not about supporting : . Do you remember what those are?
>
> I reverted those changes from both the files and ran "meson test". I
> did not observe any failure. It seems those changes are not needed.
> But adding them as a separate commit (0004) in case CI bot reveals any
> failures without them.
>
> I noticed that there were no ECPG tests for SQL/PGQ. Added a basic
> test in patch 0003.
>
> >
> > I spotted some examples that use : in ddl.sgml.
> > <programlisting>
> > SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
> > (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
> > COLUMNS (c.name AS customer_name));
> > </programlisting>
> >
> > The query demonstrates that one can use label names in a way that will
> > make the pattern look like an English sentence. Replacing : with IS
> > defeats that purpose.
> >
> > As written in that paragraph, the labels serve the purpose of exposing
> > the table with a different logical view (using different label and
> > property names). So we need that paragraph, but I think we should
> > change the example to use IS instead of :. Attached is suggested
> > minimal change, but I am not happy with it. Another possibility is we
> > completely remove that paragraph; I don't think we need to discuss all
> > possible usages the users will come up with.
> >
> > The patch changes one more instance of : by IS. But that's straight forward.
> >
> > In ddl.sgml I noticed a seemingly incomplete sentence
> >    A property graph is a way to represent database contents, instead of using
> >    relational structures such as tables.
> >
> > Represent the contents as what? I feel the complete sentence should be
> > one of the following
> > property graph is a way to represent database contents as a graph,
> > instead of representing those as relational structures OR
> > property graph is another way to represent database contents instead
> > of using relational structures such as tables
> >
> > But I can't figure out what was originally intended.
>
>
> 0002 contains some edits to this part of documentation. I think the
> paragraph reads better than before. Let me know what you think.
>
> Please let me know which of 0002 to 0004 look good to you. I will
> squash those into the patchset in the next version.

The previous patchset had a whitespace difference in ECPG expected
output files. Fixed in the attached patchset.

-- 
Best Wishes,
Ashutosh Bapat

  92. Re: SQL Property Graph Queries (SQL/PGQ)

    Henson Choi <assam258@gmail.com> — 2025-12-31T06:23:13Z

    SQL/PGQ Patch Review Report
============================

Patch: SQL Property Graph Queries (SQL/PGQ)
Commitfest: https://commitfest.postgresql.org/patch/4904

Review Methodology:
  This review focused on quality assessment, not line-by-line code audit.
  Key code paths and quality issues were examined with surrounding context
  when concerns arose. Documentation files were reviewed with AI-assisted
  grammar and typo checking. Code coverage was measured using gcov and
  custom analysis tools.

Limitations:
  - Not a security audit or formal verification
  - Parser and executor internals reviewed at module level, not exhaustively
  - Performance characteristics not benchmarked


TABLE OF CONTENTS
-----------------

1. Executive Summary
2. Issues Found
   2.1 Critical / Major
   2.2 Minor Issues
   2.3 Suggestions for Discussion
3. Test Coverage
   3.1 Covered Areas
   3.2 Untested Items
   3.3 Unimplemented Features (No Test Needed)
4. Code Coverage Analysis
   4.1 Overall Coverage
   4.2 Coverage by File
   4.3 Uncovered Code Risk Assessment
5. Recommended Additional Tests
   5.1 Black-box Tests (Functional)
   5.2 White-box Tests (Coverage)
   5.3 Untestable Code (Defensive)
6. Recommendations
7. Conclusion


1. EXECUTIVE SUMMARY
--------------------

Overall assessment: GOOD

The SQL/PGQ patch demonstrates solid implementation quality within its
defined scope. Code follows PostgreSQL coding standards, test coverage
is comprehensive at 90.5%, and documentation is thorough with only
minor typos.

Rating by Area:
- Code Quality:     Excellent (PostgreSQL style compliant, 1 FIXME)
- Test Coverage:    Good (90.5% line coverage, ~180 test cases)
- Documentation:    Good (Complete, 5 minor issues)
- Build/Regress:    Pass (make check-world, 56 test suites passed)


2. ISSUES FOUND
---------------

2.1 Critical / Major
(None)

2.2 Minor Issues

#1 [Code] src/backend/commands/propgraphcmds.c:1632
   FIXME: Missing index for plppropid column causes sequential scan.
   Decision needed: (a) add index, or (c) allow seq scan for rare path.

#2 [Doc] doc/src/sgml/ref/alter_property_graph.sgml:286
   Compatibility section incorrectly states "CREATE PROPERTY GRAPH"
   Should be: "ALTER PROPERTY GRAPH"

#3 [Doc] doc/src/sgml/ref/alter_property_graph.sgml:65
   Synopsis shows VERTEX/NODE and EDGE/RELATIONSHIP as separate clauses,
   but Description merges them as {VERTEX|NODE|EDGE|RELATIONSHIP}.

#4 [Doc] doc/src/sgml/ref/alter_property_graph.sgml:80
   Grammar error: "the graph removed" should be "the graph is removed"

#5 [Doc] doc/src/sgml/queries.sgml:2929,2931
   TODO comments for unimplemented features without clear limitation notes.

#6 [Doc] doc/src/sgml/ddl.sgml:5717
   Typo: "infrastucture" should be "infrastructure"

2.3 Alternative Approaches for Discussion

#1 Support CREATE PROPERTY GRAPH IF NOT EXISTS
   Rationale: PostgreSQL-style extension, consistent with other DDL.

#2 Return 0 rows for non-existent labels instead of error
   Current: SELECT * FROM GRAPH_TABLE(g MATCH (a:NonExistent) ...) raises
error
   Alternative: Return empty result set instead
   Rationale: Better for exploratory queries, similar to SQL WHERE on
   non-existent values returning 0 rows rather than error.

#3 Return 0 rows when same variable has different labels
   Current: SELECT * FROM GRAPH_TABLE(g MATCH (a:Person)-[e]-(a:Company)
...)
   raises error because variable 'a' has conflicting labels.
   Alternative: Return empty result set instead
   Rationale: Logically, a node cannot be both Person AND Company,
   so 0 rows is the correct result. Consistent with standard SQL
   WHERE semantics (impossible condition = 0 rows, not error).


3. TEST COVERAGE
----------------

3.1 Covered Areas

- CREATE PROPERTY GRAPH: Empty graph, VERTEX/EDGE TABLES, KEY, LABEL,
PROPERTIES
- ALTER PROPERTY GRAPH: ADD/DROP VERTEX/EDGE, ADD/DROP LABEL, ADD/DROP
PROPERTIES
- DROP PROPERTY GRAPH: Basic DROP, IF EXISTS
- RENAME TO / SET SCHEMA: Tested in alter_generic.sql
- OWNER TO: Permission change tests
- GRAPH_TABLE queries: Pattern matching, WHERE, COLUMNS, LATERAL, etc.
- RLS integration: PERMISSIVE/RESTRICTIVE policies, inheritance/partition
tables
- Error cases: Type/collation mismatch, non-existent objects, etc.
- psql integration: \dG, \d commands
- pg_dump: Tested in t/002_pg_dump.pl

3.2 Untested Items

- CREATE TEMP PROPERTY GRAPH (Medium priority)
- DROP ... CASCADE (Low priority)
- DROP ... RESTRICT (Low priority)

3.3 Unimplemented Features (No Test Needed)

- Multiple path patterns: Parser supports, execution not implemented
- Quantifier {n,m}: Parser supports, execution not implemented


4. CODE COVERAGE ANALYSIS
-------------------------

4.1 Overall Coverage

90.5% (2,029 / 2,243 lines)

4.2 Coverage by File

propgraphcmds.c:      94.6% (DDL command processing)
rewriteGraphTable.c:  94.6% (GRAPH_TABLE rewrite)
parse_graphtable.c:   97.6% (Graph query parser)
parse_clause.c:       98.0% (FROM clause parser)
ruleutils.c:          85.1% (pg_get_propgraphdef, etc.)
pg_dump.c:            84.0% (Dump/restore)
describe.c:           88.9% (psql \dG command)

4.3 Uncovered Code Risk Assessment

Low Risk (13 items):
- Defensive code, debug functions, unimplemented feature guards

Medium Risk (1 item):
- TEMP graph functionality untested

Conclusion: Most uncovered code consists of error handling, unimplemented
feature guards, and debug utilities. No security or functional risk.


5. RECOMMENDED ADDITIONAL TESTS
-------------------------------

5.1 Black-box Tests (Functional)

Based on feature specification, independent of code structure.

Feature              Test Case                                    Priority
-------------------------------------------------------------------------------
TEMP graph           CREATE TEMP PROPERTY GRAPH                   Medium
TEMP graph           TEMP graph with permanent table reference    Medium
TEMP graph           ALTER ADD permanent table to TEMP graph      Medium
CASCADE              DROP ... CASCADE (dependent view cascade)    Low
RESTRICT             DROP ... RESTRICT (dependent object error)   Low

5.2 White-box Tests (Coverage)

Based on uncovered code paths identified in coverage analysis.

File:Line                          Test Case                      Target
Branch
-------------------------------------------------------------------------------
propgraphcmds.c:136,179,254-262    TEMP table in graph creation   Auto TEMP
conversion
propgraphcmds.c:1323,1364          ALTER ADD TEMP to perm graph   Error
branch
propgraphcmds.c:724-734            CREATE without LABEL clause    Default
label else
propgraphcmds.c:1300,1303          ALTER IF EXISTS non-existent
missing_ok branch
propgraphcmds.c:116                CREATE UNLOGGED attempt        UNLOGGED
error
execMain.c:1162-1163               DML on graph
RELKIND_PROPGRAPH
rewriteGraphTable.c:120            Multiple path patterns         Length
check
rewriteGraphTable.c:205            Quantifier usage
Quantifier error
ruleutils.c:7939-7963              Complex label VIEW deparsing
T_BoolExpr branch

5.3 Untestable Code (Defensive)

File:Line                          Reason
-------------------------------------------------------------------------------
rewriteGraphTable.c:202            PAREN_EXPR blocked at parser level
rewriteGraphTable.c:297,304,319    Cyclic pattern edge conflict -
unreachable
rewriteGraphTable.c:801-818        get_gep_kind_name - error path only
nodeFuncs.c:4585-4596,4755-4774    Walker branches - internal implementation


6. RECOMMENDATIONS
------------------

6.1 Code Review Required (Minor, Decision Needed)

Location: propgraphcmds.c:1632
Issue: FIXME - No single-column index for plppropid
Current: InvalidOid causes sequential scan
Purpose: Check property references across all labels when deleting orphaned
properties
Options:
  (a) Add index: Create new single-column index on plppropid
  (b) Use existing: NOT POSSIBLE (cannot specify plpellabelid, need all
labels)
  (c) Allow: Rare path (property deletion), sequential scan acceptable

6.2 Documentation Fixes (Minor)

- alter_property_graph.sgml: 3 typos/errors to fix
- queries.sgml: Add clear limitation notes for unimplemented features
- ddl.sgml: Fix "infrastucture" typo

6.3 Test Additions (Optional)

- CREATE TEMP PROPERTY GRAPH tests
- DROP ... CASCADE/RESTRICT tests


7. CONCLUSION
-------------

Test Quality: GOOD

Core functionality is thoroughly tested with comprehensive error case and
security (RLS) integration tests.

The patch is well-implemented within its defined scope. Identified issues
are minor documentation typos and one code decision point (FIXME).
No critical or major issues found.

Recommended actions before commit:
1. Decide on FIXME at propgraphcmds.c:1632 (index vs. allow seq scan)
2. Fix 5 documentation issues
3. Consider adding TEMP graph tests (optional but recommended)

Points for discussion (optional):
4. CREATE PROPERTY GRAPH IF NOT EXISTS support
5. Error vs. 0 rows behavior for non-existent/conflicting labels


Attachment:
- coverage_report.tar.gz (HTML coverage report generated by gcov)


---
End of Report

2025년 12월 30일 (화) PM 8:27, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>님이
작성:

> On Tue, Dec 30, 2025 at 3:14 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
> >
> > On Thu, Dec 18, 2025 at 2:45 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > >
> > > >
> > > > 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.
> > >
> > > +1.
> > >
> > > Attached patch adds a couple more test statements.
> > >
> >
> > Squashed this into the main patchset.
> >
> > > >
> > > > 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.
> > > >
> > >
> > > I was aware of ecpg and I vaguely remember we fixed something in ECPG
> > > to allow : in MATCH statement. Probably following changes in
> > > psqlscan.l and pgc.l
> > > -self                   [,()\[\].;\:\+\-\*\/\%\^\<\>\=]
> > > +self                   [,()\[\].;\:\|\+\-\*\/\%\^\<\>\=]
> > >
> > > Those changes add | after : (and not the : itself) so maybe they are
> > > not about supporting : . Do you remember what those are?
> >
> > I reverted those changes from both the files and ran "meson test". I
> > did not observe any failure. It seems those changes are not needed.
> > But adding them as a separate commit (0004) in case CI bot reveals any
> > failures without them.
> >
> > I noticed that there were no ECPG tests for SQL/PGQ. Added a basic
> > test in patch 0003.
> >
> > >
> > > I spotted some examples that use : in ddl.sgml.
> > > <programlisting>
> > > SELECT customer_name FROM GRAPH_TABLE (myshop MATCH
> > > (c:customer)-[:has]->(o:"order" WHERE o.ordered_when = current_date)
> > > COLUMNS (c.name AS customer_name));
> > > </programlisting>
> > >
> > > The query demonstrates that one can use label names in a way that will
> > > make the pattern look like an English sentence. Replacing : with IS
> > > defeats that purpose.
> > >
> > > As written in that paragraph, the labels serve the purpose of exposing
> > > the table with a different logical view (using different label and
> > > property names). So we need that paragraph, but I think we should
> > > change the example to use IS instead of :. Attached is suggested
> > > minimal change, but I am not happy with it. Another possibility is we
> > > completely remove that paragraph; I don't think we need to discuss all
> > > possible usages the users will come up with.
> > >
> > > The patch changes one more instance of : by IS. But that's straight
> forward.
> > >
> > > In ddl.sgml I noticed a seemingly incomplete sentence
> > >    A property graph is a way to represent database contents, instead
> of using
> > >    relational structures such as tables.
> > >
> > > Represent the contents as what? I feel the complete sentence should be
> > > one of the following
> > > property graph is a way to represent database contents as a graph,
> > > instead of representing those as relational structures OR
> > > property graph is another way to represent database contents instead
> > > of using relational structures such as tables
> > >
> > > But I can't figure out what was originally intended.
> >
> >
> > 0002 contains some edits to this part of documentation. I think the
> > paragraph reads better than before. Let me know what you think.
> >
> > Please let me know which of 0002 to 0004 look good to you. I will
> > squash those into the patchset in the next version.
>
> The previous patchset had a whitespace difference in ECPG expected
> output files. Fixed in the attached patchset.
>
> --
> Best Wishes,
> Ashutosh Bapat
>

  93. Re: SQL Property Graph Queries (SQL/PGQ)

    Alexander Lakhin <exclusion@gmail.com> — 2026-05-16T12:00:00Z

    Hello hackers,

Please look at an internal error produced with the following script added
to src/test/regress/sql/graph_table.sql:
CREATE TABLE x(a int);
SELECT * FROM x, GRAPH_TABLE (myshop MATCH (c IS customers) ->(l IS orders | wishlists) COLUMNS (c.name, x.a AS a));

ERROR:  XX000: plan should not reference subplan's variable
LOCATION:  finalize_plan, subselect.c:3159

Best regards,
Alexander

  94. Re: SQL Property Graph Queries (SQL/PGQ)

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2026-05-16T12:12:20Z

    Hi Alexander,

On Sat, May 16, 2026 at 5:30 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> Hello hackers,
>
> Please look at an internal error produced with the following script added
> to src/test/regress/sql/graph_table.sql:
> CREATE TABLE x(a int);
> SELECT * FROM x, GRAPH_TABLE (myshop MATCH (c IS customers) ->(l IS orders | wishlists) COLUMNS (c.name, x.a AS a));
>
> ERROR:  XX000: plan should not reference subplan's variable
> LOCATION:  finalize_plan, subselect.c:3159

Thanks for the report. It will be better to start a new thread for
SQL/PGQ issues so that they can be tracked in open items if required.

I am wondering if this issue is related to the issue reported at [1]
and has the same root cause.

[1] https://www.postgresql.org/message-id/CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com

-- 
Best Wishes,
Ashutosh Bapat

  95. Re: SQL Property Graph Queries (SQL/PGQ)

    Alexander Lakhin <exclusion@gmail.com> — 2026-05-16T13:00:00Z

    Hello Ashutosh,

16.05.2026 15:12, Ashutosh Bapat wrote:
> Thanks for the report. It will be better to start a new thread for
> SQL/PGQ issues so that they can be tracked in open items if required.

I will do so next time.

> I am wondering if this issue is related to the issue reported at [1]
> and has the same root cause.
>
> [1] https://www.postgresql.org/message-id/CAHg+QDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw@mail.gmail.com

Yes, with the 0001-Fix-assertion-failure-*.patch applied, the same query is
executed with no error.

Thank you for the reply!

Best regards,
Alexander