Sanding down some edge cases for PL/pgSQL reserved words
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Cc: Jan Behrens <jbe-mlist@magnetkern.de>
Date: 2025-04-25T21:44:05Z
Lists: pgsql-hackers
Attachments
- v1-0001-De-reserve-keywords-EXECUTE-and-STRICT-in-PL-pgSQ.patch (text/x-diff) patch v1-0001
- v1-0002-Improve-error-report-for-PL-pgSQL-reserved-word-u.patch (text/x-diff) patch v1-0002
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.
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.
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
Commits
-
Improve error report for PL/pgSQL reserved word used as a field name.
- 0836683a8977 19 (unreleased) landed
-
De-reserve keywords EXECUTE and STRICT in PL/pgSQL.
- 999f172ded2b 19 (unreleased) landed