Hi I started reviewing this patch.
so 7. 6. 2025 v 18:41 odesÃlatel Tom Lane <t...@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. > > regards, tom lane > > [1] > https://www.postgresql.org/message-id/flat/18693-65968418890877b4%40postgresql.org > >
