Robert Haas <robertmhaas@gmail.com> writes:
> 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.
> 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.
I'm not sure that the pg_hba.conf parser allows that without quotes,
but in any case it's irrelevant to the proposal to use a pg_ prefix.
We don't allow non-built-in role names to be spelled that way,
quoted or not.
> 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.
The principle I'm concerned about is not letting a configuration file
that was perfectly fine in version N silently become a security hazard
in version N+1. The only way I will accept your proposal is if we
change the pg_hba.conf parser to *require* quotes around every
role and DB name that's not meant to be a keyword, so that people get
used to that requirement. But I doubt that idea will fly.
regards, tom lane