"Chuck McDevitt" <cmcdevitt@greenplum.com> writes:
> At Teradata, we certainly interpreted the spec to allow case-preserving,
> but case-insensitive, identifiers.
Really?
As I see it, the controlling parts of the SQL spec are (SQL99 sec 5.2)
26) A <regular identifier> and a <delimited identifier> are equivalent if the <identifier body> of the
<regularidentifier> (with every letter that is a lower-case letter replaced by the corresponding
upper-caseletter or letters) and the <delimited identifier body> of the <delimited identifier> (with all
occurrences of <quote> replaced by <quote symbol> and all occurrences of <doublequote symbol> replaced by
<doublequote>), considered as the repetition of a <character string literal> that specifies a
<characterset specification> of SQL_IDENTIFIER and an implementation-defined collation that is sensitive to
case, compare equally according to the comparison rules in Subclause 8.2, "<comparison predicate>".
27) Two <delimited identifier>s are equivalent if their <delimited identifier body>s, considered as
therepetition of a <character string literal> that specifies a <character set specification> of
SQL_IDENTIFIERand an implementation-defined collation that is sensitive to case, compare equally according to
the comparison rules in Subclause 8.2, "<comparison predicate>".
Note well the "sensitive to case" bits there. Now consider
CREATE TABLE tab ( "foobar" int, "FooBar" timestamp, "FOOBAR" varchar(3));
We can *not* reject this as containing duplicate column names, else we
have certainly violated rule 27. Now what will you do with
SELECT fooBar FROM tab;
? The spec is unquestionably on the side of "you selected the varchar
column"; historical Postgres practice is on the side of "you selected
the int column". AFAICS a case-insensitive approach would have to
fail with some "I can't identify which column you mean" error. I am
interested to see where you find support for that in the spec...
regards, tom lane
