On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari <[email protected]> wrote: > > Hi, > > On Mon, 18 May 2026 at 07:37, Junwang Zhao <[email protected]> wrote: >> >> On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat >> <[email protected]> wrote: >> >> > >> >> > >> I shortened the commit message by taking essential elements from your >> > >> commit message. >> > >> >> > >> Please review the attached patch. >> > > >> > > >> > > The attached patch seems not for this thread. >> > >> > Thanks for noticing. Here's attached correct patch. >> >> The patch LGTM, thanks for taking care of this. > > > +1, LGTM > > I've changed the status in CF entry status to Ready for Committer. > https://commitfest.postgresql.org/patch/6760/
Thanks Ayush. While working on this, I found two other problems. Before we dive into those, I think we should commit the current patch. It need not wait for a solution to these problems. I was checking whether we should be expanding an empty label during the transformation stage instead of rewrite phase so that, in case the graph pattern is part of a view definition, the set of labels the empty label expression resolves to is stored in the catalogs. That way, we can create a dependency of view on the set of labels at the time of view. After discussing it with Peter Eisentraut, we feel that doing so will be good for future-proofing pg_dump of views containing graph patterns with empty labels. We will definitely need it before supporting all properties reference since the properties that the all properties reference expands to depends upon the set of labels in the label expression. We need to create dependencies between those properties and the view and hence need dependencies between labels (that the empty label expression resolves to) and the view. I will provide a patch for the same soon. When trying different things which could lead to invalidation of view if we don't add the dependency between labels (that the empty label expression resolves to) and the view, I found another way to invalidate the view. To reproduce it, run the following statements after running graph_table.sql tests. CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v WHERE v.vprop1 = 10) COLUMNS (v.elname)); BEGIN; ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL l1; ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v2 DROP LABEL l1; ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v3 DROP LABEL l1; SELECT * FROM v_empty_label; ROLLBACK; The three ALTER TABLE statements leave the label behind since it's associated with the edge tables. The SELECT statement still throws "ERROR: property "elname" for element variable "v" not found". If we expand the empty label reference in the transformation phase and record dependencies between those labels and the view, we get a different error "ERROR: no property graph element of type "vertex" has label "l1" associated with it in property graph "g1"". The first error is a bit obscure compared to the second one. So there's relative improvement. Myself and Peter thought that the second error is an artifact of the term "vertex labels" in the standard; a term which is not properly defined in the standard. There are two solutions 1. We create vertex label and edge label as separate objects and record depdencies accordingly 2. We ignore the term "vertex/edge label" in the standard and handle labels that exist in property graphs but have no associated element of required type in the query. I think this will require some corrections in standard to standardize the outcome of such queries. I will provide patches once we decide which approach to take. -- Best Wishes, Ashutosh Bapat
