Chuck McDevitt wrote:
At Teradata, we certainly interpreted the spec to allow case-preserving,
but case-insensitive, identifiers.
Users really liked it that way
My 2 thoughts:
1: It seems like this behavior of case sensitive-or-not-identifiers
could/should be a config option -- either globally for the server,
database, or at the connection/session level. Other databases *do*
support this type of granular config of misc SQL behavior -- its
essential for shared hosting environments. Without it some users just
*cant* make the switch. Quoting all an app's identifiers -- or renaming
camel-case to underscored -- show stopper.
2: Even though the spec state different (that identifiers should be
treated as case sensitive or else folded), precedence seems to have
changed that:
a) The databases that enforce this rule are fewer, I believe. IMO SQL
is now considered even higher than a 4GL language because it use is so
widespread - laymen need to use it.
b) the fact that different identifiers of mixed case could even coexist
in a table-columns or 'AS' or 'JOIN' -- really represents a more of an
err'd design -- and a case-insen option would detect this (unlike the
current behavior). It would throw an immediate ("fail fast") runtime
exception. So I think it's *safer*. (If tbl.rowId and tbl.rowid both
exist in a table or AS identifiers, something bad _will_ happen when
someone takes over a project)
If there were a new default behavior (or just config option added), my
vote would, without a doubt, be for case-insens (yet case preserving)
mode... even when using quoting identifiers. This case sen. behavior
doesn't seem to offer any advantage/safety.
ken
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
