Vertex/Edge label and view
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253341psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 08:23 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253341_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253341_1 && git checkout t253341_1Patchset v1 (message #1) is on t253341_1
Hi Peter, All,
A label in a property graph can be shared by both vertex and edge elements.
When such a label is used in a view, it can be rendered useless by dropping
that label from all vertex elements or edge elements as follows.
To run the reproducer you need to first run graph_table.sql from regression.
CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v
WHERE v.vprop1 = 10) COLUMNS (v.elname));
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;
ERROR: no property graph element of type "vertex" has label "l1"
associated with it in property graph "g1"
The three ALTER TABLE statements drop label l1 from all the vertex
elements. But that does not lead to removing that label from the property
graph since there are edge elements associated with that label. The SELECT
at the end throws an error because the rewriter can not find an element
associated with the label mentioned in the view.
Myself and Peter this problem in PGConf.dev and thought that the error is
an artifact of the term "vertex labels" (or edge label) in the standard; a
term which is not properly defined in the standard. If a label is
associated with an element types (vertex or edge) in the catalog itself
i.e. element type is also part of the unique key of catalog
pg_propgraph_label, we will be able to add a dependency between the view
and the element type specific label. This in turn will prohibit dropping
the element type specific label from the catalog. The view won't be
rendered invalid then. This isn't that straight forward since such a label
still needs to have the same properties associated with it independent of
the element type. So we need pg_propgraph_label to contain only the label
name and have a separate catalog pg_proprgaph_elem_type_label (or some
such) which associates a label with an element type. The view should add
dependency on the row in the latter catalog.
Otherwise, standard needs to define the result of the query when a label
exists but is not associated with any element of required type - which
essentially would mean returning 0 rows since there are no elements
associated with the label.
I think we need the standard to define the behaviour in such a case.
Attached patch adds a test case to graph_table.sql showing this problem. We
may want to commit the test case so that someone coming across the issue
knows that this is the expected behaviour pending for clarification from
the standard.
Oracle prohibits sharing labels across vertex and edge elements, but other
graph databases allow it and so does the SQL/PGQ standard. I think it's a
useful feature, so I'm not thinking of doing it the Oracle way myself. But
if there are more people who think otherwise, I am ok with it.
[1]: /messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
/messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
On 07.08.26 08:47, Ashutosh Bapat wrote:
Otherwise, standard needs to define the result of the query when a label
exists but is not associated with any element of required type - which
essentially would mean returning 0 rows since there are no elements
associated with the label.I think we need the standard to define the behaviour in such a case.
The standard does define that behavior: Using a label that is not
associated with an element of the right type is a syntax error.
What we are not doing correctly is that DROP LABEL should either
RESTRICT if a view exists or CASCADE, as appropriate.
So there is room for improvement, but I'm not too bothered by the
current behavior. You get a clear error message and nothing incorrect
happens.