Message-ID: <4571C133.1060200@kensystem.com>
Date: Sat, 02 Dec 2006 11:08:51 -0700
From: Ken Johanson <pg-user@kensystem.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Dennis Bjorklund <db@zigo.dhs.org>
CC: Martijn van Oosterhout <kleptog@svana.org>,  pgsql-sql@postgresql.org
Subject: Re: [HACKERS] Case Preservation disregarding case
References: <200610271623.37525.beauh@bluefrogmobile.com>
	<1162003132.687.8.camel@pampa>
	<200610301928.51255.beauh@bluefrogmobile.com>
	<23177.1162265010@sss.pgh.pa.us>
	<EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
	<45712E31.1030004@kensystem.com> <20061202133556.GC26365@svana.org>
	<457199E4.3010401@kensystem.com> <4571A3AF.6070608@zigo.dhs.org>
	<4571AE66.7050304@kensystem.com> <4571B392.6020303@zigo.dhs.org>
In-Reply-To: <4571B392.6020303@zigo.dhs.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dennis Bjorklund wrote:
>> So my vote would remain for having a config-option to ignore case, 
>> even on quoted identifiers..
> 
> And my vote is to not have such an option. But I'm not the one who 
> decide so don't worry about what I think :-) I would like to have an 
> option to upper case the identifiers instead of lower casing them as pg 
> do. The sql standard say that they should be upper cased. But as far as 
> I know there are no plan at the moment to add such an option either. 
> Some time in the future I expect it to be implemented only because it's 
> the standard.
> 
> /Dennis
> 

Ya, I thought about that - just designing with all-lower case column 
names. But then the column names are harder to read, unless I change 
over to using underscore naming.

I personally cant see any benefit at all to having the DB fold case (up 
or down), or enforcing case sensitive identifiers. In fact I believe 
that if here were an option to support case insensitive (at least on a 
session-level) that would be largely innocuous --- beneficial even since 
the optimizer would now detect that someone created both a rowId, rowid, 
and that indicates a possible design error (the whole fail-fast notion).

In one way I think that even allowing creation of a separate "rowid" and 
"rowId" sort of violates set theory in a 4+ GL language... a "name" in 
its most abstract (human) sense doesn't (shouldn't) consider the case of 
its characters. Only what the characters are. A rowid is also a rowId 
(or ROWID). Who really intentionally mixes them? (only 3-4GL 
*programmers* who consider all-caps to represent constants in my 
experience).

thoughts,
Ken