Empty label expressions and views
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:t253343psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 23, 2026 at 08:35 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 t253343_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 t253343_1 && git checkout t253343_1Patchset v1 (message #1) is on t253343_1
Hi All,
This was earlier discussed in [1]/messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com, but starting a new thread to discuss
only this issue.
We create dependencies between a view and the labels specified in the label
expressions in the view definition. An empty label expression resolves to a
disjunction between all the labels. But since there is no explicit label
mentioned we do not create dependency between any label and the view.
Further adding and dropping labels in the property graph changes the
element tables that are scanned by the query. That feels awkward - a user
who created the view may not be expecting this change. Well, one can have
the same effect if an existing label is associated with a new element table
- but at least the user is aware of the effect when they add or remove a
label to or from the element table. The awkwardness is arguable.
When we support all property references things need to change. An all
property reference [1]/messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com is resolved to all the properties associated with
all the labels specified in the element pattern. Since the shape of the
view result depends upon the properties references in the COLUMNs clause,
an all property reference can not be stored in the view definition as an
all property reference. Instead the expanded form of all property reference
needs to be stored in the catalog. This is in line with how we store a * in
the target list in the view definition. This requires resolving an all
property reference during transformation phase itself. This means that we
have to resolve an empty label expression during the transformation phase
itself. This, in turn, means an empty label expression in the view
definition will be stored as disjunction of all labels in the catalogs. As
explained earlier, this is different from what we do today and may result
in a backward in-compatibility. So I think we should discuss whether we
need to fix the empty label expression resolution now and avoid backward
compatibility or tackle the problem when we will support all properties
reference. Just backporting the changes to query transformation are not
enough to fix the backward incompatibility since already created views
won't be fixed that way - they will need to be recreated.
PFA the patch which fixes the transformation of empty label expression. The
patch might need some work. The patch may be considered invasive at this
late stage in the PG 19. For that reason I am fine to defer this to PG 20
or whenever we support all properties reference.
[1]: /messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
/messages/by-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
[2]: /messages/by-id/CAExHW5tYCE9QyCvVraKUeesKW5RTR+mrzsg3u64qSps-RPJR5A@mail.gmail.com
/messages/by-id/CAExHW5tYCE9QyCvVraKUeesKW5RTR+mrzsg3u64qSps-RPJR5A@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
On 07.08.26 11:23, Ashutosh Bapat wrote:
We create dependencies between a view and the labels specified in the
label expressions in the view definition. An empty label expression
resolves to a disjunction between all the labels. But since there is no
explicit label mentioned we do not create dependency between any label
and the view. Further adding and dropping labels in the property graph
changes the element tables that are scanned by the query. That feels
awkward - a user who created the view may not be expecting this change.
Well, one can have the same effect if an existing label is associated
with a new element table - but at least the user is aware of the
effect when they add or remove a label to or from the element table. The
awkwardness is arguable.
But this is how it is meant to work. You are arguing that the set of
labels should be frozen when the view is parsed, which could be equally
confusing, considering that we don't prevent new labels from being added.
When we support all property references things need to change. An all
property reference [1] is resolved to all the properties associated with
all the labels specified in the element pattern. Since the shape of the
view result depends upon the properties references in the COLUMNs
clause, an all property reference can not be stored in the view
definition as an all property reference. Instead the expanded form of
all property reference needs to be stored in the catalog. This is in
line with how we store a * in the target list in the view definition.
This requires resolving an all property reference during transformation
phase itself. This means that we have to resolve an empty label
expression during the transformation phase itself. This, in turn, means
an empty label expression in the view definition will be stored as
disjunction of all labels in the catalogs.
Maybe we need to do some more analysis on this chain of reasoning and
where the problem lies. I'm tempted to think that the way empty label
expressions behave now is correct, and then the fix should lie in some
other steps.