quoting behavior

Dave Page and I were discussing the word "name" this morning. I said
"I like to use a column called 'name' in a lot of my tables" and he
said "I don't like to do that because the quoting is really annoying"
and I said "what quoting?". Long story short, it turns out that
postgresql and pgdump do not quote the word name, but pgadmin does.
The reason for this is that pgadmin quotes all keywords, even
unreserved keywords, except for type names, when it quotes all
keywords except for a fixed list that is hardcoded into the
needsQuoting() function.

Attached, please find a patch that brings the behavior more closely
into alignment with what core PG does. It skips quoting all
UNRESERVED_KEYWORDs, and when forTypes is true, it also skips quoting
COL_NAME_KEYWORDs. It might also be safe to skip quoting
TYPE_FUNC_NAME_KEYWORDs when forTypes is false, but I opted not to do
in this patch that because I'm less sure of whether it's safe. Not
quoting UNRESERVED_KEYWORDs seems pretty safe because an unreserved
keyword can't be used in the grammar in any place where a column name,
type name, function name, or table name can appear. There shouldn't
ever be any possibility of confusing an unreserved keyword with an
identifier, so they don't need to be quoted (see, e.g.,
quote_identifier() in src/backend/utils/adt/ruleutils.c). Not quoting
COL_NAME_KEYWORDs when forTypes is true should have about the same
effect as the current hardcoded list, because basically that's just a
list of all of the buitin types that happen to also be
COL_NAME_KEYWORDs. The differences are (1) if someone happens to
define a type with the same name as a current or future
COL_NAME_KEYWORD, the new coding will avoid quoting it unnecessarily;
and (2) if the keyword ANY is used as a type name, it will be quoted,
which is a good thing, because that's required, and the inclusion of
that name into the current list appears to be an error, since any is
in fact a RESERVED_KEYWORD.

Have mercy on me if this patch is stupid, badly formatted, submitted
incorrectly, or otherwise poorly-thought-out. I'm new here. :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company