Re: quoting behavior

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