Re: (SQL/PGQ) cache lookup failed for label

On Fri, May 22, 2026 at 12:07 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
> <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> >>
> >> On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
> >> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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.

While working on this I found another issue. An empty label expression
may turn into no label which does not have any syntax level support.
Hence we can't dump a view containing such an empty label expression.
For now I have prohibited empty label expressions which do not resolve
to any label as an unsupported feature. I doubt if there will be any
valid use case for such a label expression.

As a result a test which tests dependency between a view and the
property graph in create_property_graph.sql failed. Failure is
accidental as test uses an empty property graph for this purpose. I
fixed it by adding a vertex table to the property graph being
referenced in the view.

The commit message just mentions the label dependency asymmetry
between explicitly mentioned labels and labels resulting from empty
label expression. I haven't gone into the details of
all-properties-reference to keep it simple. The discussion link should
lead a curious reader to the complex discussion here.

I did reconsider whether to fix this right now or whether we can
postpone it till we support all-properties reference. If we don't fix
this, a query containing empty label expression will return different
result as the set of labels in the property graph changes. When we
will support all properties reference, we will have to fix this and
then the behaviour will change breaking backward compatibility. So I
think we have to fix this now.

>
> 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.

For now I have added a test case exhibiting this behaviour. If we
commit the test, somebody who comes across this behaviour will know
why the current behaviour is the way it is and what's the way forward.
But if we don't commit it, which is ok, they will consider this as
buggy behaviour and report it. I am fine either way.

As I mentioned earlier, I am creating patches for all outstanding
issues from the same branch. So the patches attached here do not start
from 0001, but they apply with git am on the latest master for me
without any problem.
0005 - fixes `cache lookup failed for label`
0006 - fixes empty label expression and view behaviour
0007 - issue with labels shared by vertex and edges

--
Best Wishes,
Ashutosh Bapat