Alvaro Herrera wrote:
Randall Smith wrote:
Scott Marlowe wrote:
This whole discussion is reminding me of one of my personal mantras, and
that is that relying on "artifacts" of behaviour is generally a bad
idea.
For instance, many databases accept != for not equal, but the sql
standard quite clearly says it's <>.
If you're relying on case folding meaning that you don't have to
consistently use the same capitalization when referring to variables,
table names, people, or anything else, you're asking for trouble down
the line, and for little or no real gain today.
I know that a lot of times we are stuck with some commercial package
that we can't do anything to fix, so I'm not aiming this comment at the
average dba, but at the developer.
Yea, this is a commercial package, but it's actually doing it right.
Since it doesn't know how a user will name a table or column, it always
calls them as quoted strings in upper case which is standards compliant,
but doesn't work with PG. So if a user names a table 55 and mine, it
calls "55 AND MINE" and for foo, it calls "FOO". Looks like they did it
right to me.
So what's the problem? Just create the tables as all uppercase and you
should be fine, since the application must be systematic about quoting.
The toolkit uses quoted identifiers and the application doesn't. I have
a solution, which is to use views, but this thread is now about whether
or not Postgresql should and will support the current SQL standard,
which is to convert non-quoted identifiers to upper case. Postgresql
converts them to lower case and that is the issue. Since posting this
thread I've found this topic hashed out before in pgsql-hackers (thanks
Tom).
Randall