Thread

Re: SQL Property Graph Queries (SQL/PGQ)

Peter Eisentraut <peter@eisentraut.org> — 2025-12-17T08:58:22Z

On 17.12.25 06:32, Ashutosh Bapat wrote:
> On Mon, Dec 15, 2025 at 6:43 PM Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>>
>> Rebased patches on the latest HEAD which required me to move
>> graph_table.sql to another parallel group.
> 
> Huh, the movement resulted in losing that test from parallel_schedule.
> Fixed in the attached patches.

A couple of items:

1) I was running some tests that involved properties with mismatching 
typmods, and I got an error message like

ERROR:  property "p1" data type modifier mismatch: 14 vs. 19

but the actual types were varchar(10) and varchar(15).  So to improve 
that, we need to run these through the typmod formatting routines, not 
just print the raw typmod numbers.  I actually just combined that with 
the check for the type itself.  Also, there was no test covering this, 
so I added one.  See attached patches.

I did another investigation about whether this level of checking is 
necessary.  I think according to the letter of the SQL standard, the 
typmods must indeed match.  It seems Oracle does not check (the example 
mentioned above came from an Oracle source).  But I think it's okay to 
keep the check.  In PostgreSQL, it is much less common to write like 
varchar(1000).  And we can always consider relaxing it later.

2) I had it in my notes to consider whether we should support the colon 
syntax for label expressions.  I think we might have talked about that 
before.

I'm now leaning toward not supporting it in the first iteration.  I 
don't know that we have fully explored possible conflicts with host 
variable syntax in ecpg and psql and the like.  Maybe avoid that for now.

There was also a bit of an inconsistency in the presentation: The 
documentation introduced the colon as seemingly the preferred syntax, 
but ruleutils.c dumped out the IS syntax.

(It was also a bit curious that some test code put spaces around the 
colon, which is not idiomatic.)

Looking around at other implementations: Oracle does not support it; 
DuckDB supports it, but it doesn't seem to be very up to date, so I 
don't know what the thinking there is; Google does support it, but it 
seems their syntax is more of a PGQ-GQL hybrid, so it's not a good 
reference.

Attached is a patch that shows how to revert the colon support.  It's 
pretty simple, and it would be easy to add it back in later, I think.