so 7. 6. 2025 v 18:41 odesílatel Tom Lane <tgl@sss.pgh.pa.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.
