Re: SQL Property Graph Queries (SQL/PGQ)

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: assam258(at)gmail(dot)com, Amit Langote <amitlangote09(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Ajay Pal <ajay(dot)pal(dot)k(at)gmail(dot)com>, Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Date: 2026-02-27 08:44:03
Message-ID: CAExHW5vq8e++jtXRvhYRFVHQ79MxuNoZnjeAF3_82+E1sBoydg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 27, 2026 at 1:14 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 26.02.26 12:06, Ashutosh Bapat wrote:
> > All changes to rewriteGraphTable.c are in 0004.
> >
> > Will squash 0002-0004 into 0001 once you have reviewed those patches.
>
> Ok, these all look good to me.
>
> Except, this error message change
>
> -ERROR: property "ename" of element variable "src" not found
> +ERROR: none of the property graph elements associated with variable
> "src" have property with name "ename" defined
>
> I don't know, that seems quite a complicated message for such a simple
> mistake. Also, properties are associated with labels, not with graph
> elements, so this seems misleading.
>

Hmm, mentioning labels was getting even more complicated, so I had to drop it.

How about the earlier version with "of" replaced with "for"? "property
"ename" for element variable "src" not found. The users can lookup the
labels associated with variable src and figure out what went wrong
themselves? I want to avoid simplistic error that other products give
like "property "ename" not found" since it does not clarify whether
the property is absent in the property graph or is not associated with
labels in the pattern.

--
Best Wishes,
Ashutosh Bapat

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message zhanghu 2026-02-27 08:46:12 Re: guc: make dereference style consistent in check_backtrace_functions
Previous Message Andrei Lepikhov 2026-02-27 08:33:48 Re: Convert ALL SubLinks to ANY SubLinks