Horton

Re: SQL Property Graph Queries (SQL/PGQ)

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: Vik Fearing <vik@postgresfriends.org>, Ajay Pal <ajay.pal.k@gmail.com>, Imran Zaheer <imran.zhir@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-01T09:01:59Z
Lists: pgsql-hackers

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

Attachments

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