On Thu, Jan 9, 2020 at 11:06 AM Tom Lane <t...@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
