Re: SQL Property Graph Queries (SQL/PGQ)

On Wed, Mar 11, 2026 at 1:04 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> There are two new patches 0004 and 0005 in the attached patchset.
> Below is a description of those.
>
> All property reference and refactoring
> --------------------------------------------------
> According to the SQL/PGQ standard, all properties reference
> <variable>.* is allowed in COLUMNs, but it's not allowed anywhere else
> e.g. in WHERE clause or buried inside a value expression. The current
> error message is misleading in saying ""*" not allowed here". Instead
> it should say "not supported" in COLUMNs and "not allowed" in other
> places. Patch 0004 is the patch fixing the error message. It is not
> accurate since it only checks whether <variable>.* appears in COLUMNs
> clause or not. It doesn't differentiate between it appearing directly
> in COLUMNs vs buried in another value expression. But I think it
> serves the purpose for now. It's a limitation that we will eventually
> remove. So it may be ok.
>
> I attempted to support it and turned out to be relatively simple. So
> we can support it in the first version itself. However, the patch is
> much larger. In order to expand all properties reference, we need to
> find all the properties associated with the set of labels which
> results from evaluating label expression. The properties are not
> directly associated with a label, but through an element. Hence we
> need to find at least one element associated with each label in the set.
> Further the set of labels that an empty label expression results into
> is all the labels which have at least one element of a given element
> kind in the property graph. That's another reason why we want to find
> at least one element associated with each of the labels. If we are
> looking up element label catalog, why not to fetch all the elements
> during transformation itself rather than waiting all the way till
> the rewriting phase. So I changed the code to do that. And I think the
> resultant code is much simpler, moves the error handling to
> appropriate places and simplifies a lot of the rewriteGraphTable.c
> code. Flip side is transform* functions are heavier, however in the
> end it's code simplification. Since we are expanding the empty label
> expression during transformation phase itself, we replace empty label
> expression with a disjunction. But we need to know whether the
> original label expression was empty or not in the ruleutils and when
> consolidating path elements (generate_queries_for_path_pattern()). The
> later usage will vanish once we support label disjunction. So I
> introduced a flag to retain that status. All that refactoring is patch
> 0005.
>
> Peter, if you think 0005 is larger to be acceptable at this stage, we
> could revisit it later as well.
>
> In order to apply 0005, 0004 is needed even though 0005 nullifies that
> change. I have separated 0004, so that those changes can be committed
> even if we decide to postpone 0005.
>

I have missed adding pg_node_attr(equal_ignore, query_jumble_ignore)
to the three new fields in GraphLabelRef, since the equality of other
fields is enough and those three fields don't need to be part of query
jumbling. If a node with those fields populated is written ignoring
those fields, what would resurrect those fields when read back? I
don't think there is anything that would do it. So didn't add
read_write_ignore. But I am not sure.

List *properties pg_node_attr(equal_ignore, query_jumble_ignore);
List *elements pg_node_attr(equal_ignore, query_jumble_ignore);
List *elem_labels pg_node_attr(equal_ignore, query_jumble_ignore);

--
Best Wishes,
Ashutosh Bapat