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