Matthew wrote:
Tom Lane wrote:
Although ... it's true that there seem to be very few apps relying on
case sensitivity per se, ie, expecting "Foo" and "foo" to be different.
The complaints that I can remember were about programs that expected
"FOO" and FOO (not quoted) to be the same. So always-smash-to-lower-
case might indeed solve most of the real-world problem for the Oracle
camp as well.
Is it worth having a GUC variable that enables / disable this? I
hate to add GUCs but this seems like a fairly significant change in
expected behavior. Not sure it's a good idea, but I thought I should
ask the question anyway.
It is a good idea for a very simple reason. When given a choice between
standards-compliance and backwards-compatibility with prior versions, it
is important to give the option to make this change. The only other
option is to make it a initdb time decision.
Autocommit is a bad example. A better option is the GUC variable that
allows you to go back to the way we used to do things and allow NULL =
NULL to return TRUE instead of NULL. In both these cases, the
difference is a semantic change in what a given SQL statement means.
Best Wishes,
Chris Travers
Metatron Technology Consulting
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
