On Thu, Jan 9, 2020 at 11:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The problem is that we keep deciding that okay, it probably won't hurt
> anybody if this particular thing-that-ought-to-be-a-reserved-word isn't
> really reserved. Your exercise in justifying that for "superuser" is
> not unlike every other previous argument about this. Sooner or later
> that's going to fail, and somebody's going to have a security problem
> because they didn't know that a particular name has magic properties
> in a particular context. (Which, indeed, maybe it didn't have when
> they chose it.) Claiming they should have known better isn't where
> I want to be when that happens.
But, again, we already *have* a way of solving this problem: use
quotes. As Simon pointed out, your proposed solution isn't really a
solution at all, because & can appear in role names. It probably
won't, but there probably also won't be a role name that matches
either of these keywords, so it's just six of one, half a dozen of the
other. The thing that really solves it is quoting.
Now I admit that if we decide pg_hba.conf keywords have to start with
"pg_" and prevent names beginning with "pg_" from being used as object
names, then we'd have TWO ways of distinguishing between a keyword and
an object name. But I don't think TMTOWTDI is the right design
principle here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
