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

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.

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
>
>