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

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.

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.

--
Best Wishes,
Ashutosh Bapat