Re: Sanding down some edge cases for PL/pgSQL reserved words

Hi

ne 8. 6. 2025 v 6:25 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

> Hi
>
> I started reviewing this patch.
>
>
> so 7. 6. 2025 v 18:41 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>
>> This is a rather delayed response to the discussion of bug
>> #18693 [1], in which I wrote:
>>
>> > (It's kind of annoying that "strict" has to be double-quoted
>> > in the RAISE NOTICE, especially since you get a rather misleading
>> > error if it isn't. But that seems like a different discussion.)
>>
>> As an example of that, if you don't double-quote "strict"
>> in this usage you get
>>
>> regression=# do $$ declare r record; begin
>> SELECT a, b AS STRICT INTO r FROM (SELECT 'A' AS a, 'B' AS b) AS q;
>> RAISE NOTICE 'STRICT r.strict = %', r.strict;
>> end $$;
>> ERROR: record "r" has no field "strict"
>> LINE 1: r.strict
>> ^
>> QUERY: r.strict
>> CONTEXT: PL/pgSQL function inline_code_block line 3 at RAISE
>>
>> which is pretty bogus because the record *does* have a field
>> named "strict". The actual problem is that STRICT is a fully
>> reserved PL/pgSQL keyword, which means you need to double-quote
>> it if you want to use it this way.
>>
>> The attached patches provide two independent responses to that:
>>
>> 1. AFAICS, there is no real reason for STRICT to be a reserved
>> rather than unreserved PL/pgSQL keyword, and for that matter not
>> EXECUTE either. Making them unreserved does allow some ambiguity,
>> but I don't think there's any surprises in how that ambiguity
>> would be resolved; and certainly we've preferred ambiguity over
>> introducing new reserved keywords in PL/pgSQL before. I think
>> these two just escaped that treatment by dint of being ancient.
>>
>
> There is no issue.
>
>
>
>>
>> 2. That "has no field" error message is flat-out wrong. The now-known
>> way to trigger it has a different cause, and what's more, we simply do
>> not know at this point whether the malleable record type has such a
>> field. So in 0002 below I just changed it to assume that the problem
>> is a reserved field name. We might find another way to reach that
>> failure in future, but I doubt that "has no field" would be the right
>> thing to say in any case.
>>
>
> The proposed patch is a zero invasive solution. But the question is why we
> cannot allow plpgsql reserved keywords in recfilds?
>
> There should not be any collisions. Isn't there a better solution to
> modify plpgsql_yylex instead and allow all keywords after '.' ? Sure. It
> will be more invasive.
>

Looks so nobody has any motivation to do some deeper changes to reduce
prohibition of reserved words. It is true, so in the real world it is not
an issue.

I did a review, and I didn't find any issue.

All tests passed without problems. I'll mark this patch as ready for commit.

Maybe the usage of unreserved words as variables or field names can be
tested a little bit more. See patch 0003

Regards

Pavel

>
> Regards
>
> Pavel
>
>
>
>
>> This is v19 material at this point, so I'll stick it on the CF queue.
>>
>> regards, tom lane
>>
>> [1]
>> https://www.postgresql.org/message-id/flat/18693-65968418890877b4%40postgresql.org
>>
>>