Thread: quoting behavior

quoting behavior

From
Robert Haas
Date:
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

Attachment

Re: quoting behavior

From
Guillaume Lelarge
Date:
Le 27/08/2010 23:18, Robert Haas a écrit :
> 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.  :-)
>

:)

Seems good to me. Applied to the master branch.

Thanks again.


--
Guillaume
 http://www.postgresql.fr
 http://dalibo.com