On Thu, Jan 9, 2020 at 10:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What I'm basically objecting to is the pseudo-reservedness. If we
> don't want to dodge that with special syntax, we should dodge it
> by making sure the keywords are actually reserved names.
You know, as I was reading this email, I got to thinking: aren't we
engineering a solution to a problem for which we already have a
solution?
The documentation says:
"Quoting one of the keywords in a database, user, or address field
(e.g., all or replication) makes the word lose its special character,
and just match a database, user, or host with that name."
So if you've writing a pg_hba.conf file that contains a specific role
name, and you want to make sure it doesn't get confused with a current
or future keyword, just quote it. If you don't quote it, make sure to
RTFM at the time and when upgrading.
If you want to argue that this isn't the cleanest possible solution to
the problem, I think I would agree. If we were doing this over again,
we could probably design a better syntax for pg_hba.conf, perhaps one
where all specific role names have to be quoted and anything that's
not quoted is expected to be a keyword. But, as it is, nothing's
really broken here, and practical confusion is unlikely. If someone
has a role named "superuser", then it's probably a superuser account,
and the worst that will happen is that we'll match all superuser
accounts rather than only that one. If someone has a non-superuser
account called "superuser", or if they have an account named
"nonsuperuser," then, uh, that's lame, and if this patch causes them
to improve their choice of role names, that's good. If it causes them
to use quotes, that's also good.
But I think I'm coming around to the view that we're making what ought
to be a simple change complicated, and we should just not do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
