Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Re: [HACKERS] Case Preservation disregarding case
Date: Tue, 31 Oct 2006 01:08:31 -0500
Message-ID: <EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
Thread-Topic: [HACKERS] [SQL] Case Preservation disregarding case sensitivity?
thread-index: Acb8nAzHYq/k7VCLQUGyPsNB+Yf4GAAFZ7aw
References: <200610271623.37525.beauh@bluefrogmobile.com>
	<1162003132.687.8.camel@pampa>
	<200610301928.51255.beauh@bluefrogmobile.com>
	<23177.1162265010@sss.pgh.pa.us>
From: "Chuck McDevitt" <cmcdevitt@greenplum.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>,
	"beau hargis" <beauh@bluefrogmobile.com>
cc: pgsql-sql@postgresql.org,
	pgsql-hackers@postgresql.org
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

At Teradata, we certainly interpreted the spec to allow case-preserving,
but case-insensitive, identifiers.
Users really liked it that way:  If you re-created a CREATE TABLE
statement from the catalog, you could get back exactly the case the user
had entered, but people using the table didn't need to worry about case.
And column titles in reports would have the nice case preserving
information.
Sort of like how Windows systems treat file names... The case is
preserved, but you don't need to know it to access the file.

I know UNIX users usually think "case-preserving with case-insensitive"
a foreign concept, but that doesn't mean the average user feels the
same.

If I want my column named "WeeklyTotalSales", I really don't want to
have to always quote it and type in the exact case.

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Monday, October 30, 2006 7:24 PM
To: beau hargis
Cc: pgsql-sql@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [SQL] Case Preservation disregarding case
sensitivity?

beau hargis <beauh@bluefrogmobile.com> writes:
> Considering the differences that already exist between database
systems and=20
> their varying compliance with SQL and the various extensions that have
been=20
> created, I do not consider that the preservation of case for
identifiers=20
> would violate any SQL standard.

That's not how I read the spec.  It is true that we are not 100% spec
compliant, but that isn't a good argument for moving further away from
spec.  Not to mention breaking backwards compatibility with our
historical behavior.  The change you propose would fix your application
at the cost of breaking other people's applications.   Perhaps you
should consider fixing your app instead.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org