diff options
author | Tom Lane | 2025-07-11 22:50:13 +0000 |
---|---|---|
committer | Tom Lane | 2025-07-11 22:50:13 +0000 |
commit | 64840e46243a5f672b9e2fcb8d93c63daec4bc9a (patch) | |
tree | 195ff2584fec56132208e9af01e4932a7a6b40c1 /src/test/regress/expected/comments.out | |
parent | 990571a08b66c76be85b077ddcba419fd4524952 (diff) |
getid() and putid(), which parse and deparse role names within ACL
input/output, applied isalnum() to see if a character within a role
name requires quoting. They did this even for non-ASCII characters,
which is problematic because the results would depend on encoding,
locale, and perhaps even platform. So it's possible that putid()
could elect not to quote some string that, later in some other
environment, getid() will decide is not a valid identifier, causing
dump/reload or similar failures.
To fix this in a way that won't risk interoperability problems
with unpatched versions, make getid() treat any non-ASCII as a
legitimate identifier character (hence not requiring quotes),
while making putid() treat any non-ASCII as requiring quoting.
We could remove the resulting excess quoting once we feel that
no unpatched servers remain in the wild, but that'll be years.
A lesser problem is that getid() did the wrong thing with an input
consisting of just two double quotes (""). That has to represent an
empty string, but getid() read it as a single double quote instead.
The case cannot arise in the normal course of events, since we don't
allow empty-string role names. But let's fix it while we're here.
Although we've not heard field reports of problems with non-ASCII
role names, there's clearly a hazard there, so back-patch to all
supported versions.
Reported-by: Peter Eisentraut <[email protected]>
Author: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 13
Diffstat (limited to 'src/test/regress/expected/comments.out')
0 files changed, 0 insertions, 0 deletions