Re: SELECT problem

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> The mention of a transformation to upper-case is what Andrew is
> referring to; PostgreSQL historically has transformed to lower case and
> so far we are too stubborn to change it just because it has become a
> standard ;)

See also the example and footnote at the end of section 1.1.1 of the
user's guide,
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS

The fact that Postgres deviates from the spec is only visible if you
sometimes use a name with quotes and sometimes without: foo with no
quotes (and any casing) is equivalent to "FOO" per spec but "foo" per
Postgres. Expecting a mixed-case quoted identifier to be equivalent
to an unquoted identifier is wrong either way.

(There are reasons other than stubbornness for not wanting to conform
exactly to the spec on this point. In particular, it's well established
that lower-case text is more readable than upper-case, and so we'd take
a nontrivial usability hit if the system started storing and reporting
names in upper case.)

If the original report is correct then SQL Server matches names
case-insensitively (at least when they're not quoted), which seems
a much larger departure from the spec behavior to me. For example,
I'd think they'd have to reject table definitions that contain
columns named both "foo" and "FOO", else they'd have
effectively-duplicate column names. Can anyone verify their behavior?

regards, tom lane