X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP
	id 4143AD1B98D; Fri, 23 Apr 2004 14:10:36 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 99648-01; Fri, 23 Apr 2004 14:10:33 -0300 (ADT)
Received: from trolak.mydnsbox2.com (ns1.mydnsbox2.com [207.44.142.118])
	by svr1.postgresql.org (Postfix) with ESMTP
	id 6780DD1B560; Fri, 23 Apr 2004 14:10:32 -0300 (ADT)
Received: from dunslane.net (x.ncshp.org [199.90.235.43])
	(authenticated (0 bits))
	by trolak.mydnsbox2.com (8.11.6/8.11.6) with ESMTP id i3NHCBK11281;
	Fri, 23 Apr 2004 12:12:11 -0500
Message-ID: <40894E5A.4060102@dunslane.net>
Date: Fri, 23 Apr 2004 13:11:54 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PostgreSQL advocacy <pgsql-advocacy@postgresql.org>
Subject: Re: [HACKERS] What can we learn from MySQL?
References: <Pine.LNX.4.44.0404231117270.4551-100000@zigo.dhs.org>
	<1082735128.22969.1106.camel@camel>
	<20040423094236.J17459@megazone.bigpanda.com>
In-Reply-To: <20040423094236.J17459@megazone.bigpanda.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200404/224
X-Sequence-Number: 4196

Stephan Szabo wrote:

>>I know this to be true, but don't fully understand it... if our default
>>behavior is to fold lower, and we change it to just fold upper... then
>>in theory this shouldn't break anything since what used to be folder
>>lower will now simply be folder upper. the only people who will have a
>>problem are those who quote on one end but not the other, which is bad
>>practice anyways...  so i would say if your serious about it, make the
>>patch as GUC "case_folding" for upper or lower and get a taste for what
>>breaks inside the db.
>>    
>>
>
>I've tried just changing the parser to unconditionally casefold to upper.
>First thing that happens is that initdb breaks. In addition, you have
>potential issues with comparisons against the catalog's versions of
>standard functions as such if you allow the case folding to be changed
>after the catalogs are setup.
>
>  
>

ISTM that rather than a having a GUC setting, initdb would be the right 
time to make this choice. I'm not saying it would be easy, but it seems 
(without looking into it deeply) at least possible.

cheers

andrew