Empty label expressions and views

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Empty label expressions and views
Date: 2026-08-07 09:23:56
Message-ID: CAExHW5tcik5NgSy9nn9kUYme82fFUYyon=hmrV0pXWhALoxJBw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi All,

This was earlier discussed in [1], 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] 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]
https://www.postgresql.org/message-id/CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAExHW5tYCE9QyCvVraKUeesKW5RTR+mrzsg3u64qSps-RPJR5A@mail.gmail.com

--
Best Wishes,
Ashutosh Bapat

Attachment Content-Type Size
v20260807-0001-Empty-label-expression-in-view-definition.patch text/x-patch 19.6 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-08-07 09:37:55 Re: COPY TO BLACKHOLE / pg_dump -j -Fb
Previous Message Hayato Kuroda (Fujitsu) 2026-08-07 09:07:06 Random 038_walsnd_shutdown_timeout.pl failure on goldfish