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.
