Re: [SQL] Case Preservation disregarding case

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