Re: Empty label expressions and views

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Empty label expressions and views
Date: 2026-08-17 13:26:34
Message-ID: fdacf0b4-3fc7-41ba-ab31-a6f58ef95e9d@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-08-17 13:27:32 Re: Logical replication row filter loses unchanged toasted columns
Previous Message Xuneng Zhou 2026-08-17 13:20:08 Re: [WIP] Pipelined Recovery