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.
Is there some description of what keywords should be reserved? If I remember correctly, the scanner was changed more times, and maybe more reserved keywords are not necessary.
Regards
Pavel
Regards
Pavel
This is v19 material at this point, so I'll stick it on the CF queue.
