Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 1D4949FB299; Thu, 2 Nov 2006 11:51:49 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 01500-07; Thu, 2 Nov 2006 15:51:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B983D9FB298; Thu, 2 Nov 2006 11:51:45 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kA2FpPPd016898; Thu, 2 Nov 2006 10:51:25 -0500 (EST) To: "Simon Riggs" cc: "Chuck McDevitt" , "Stephan Szabo" , "beau hargis" , pgsql-sql@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Case Preservation disregarding case In-reply-to: <1162463264.3587.281.camel@silverbirch.site> References: <200610271623.37525.beauh@bluefrogmobile.com> <1162003132.687.8.camel@pampa> <200610301928.51255.beauh@bluefrogmobile.com> <23177.1162265010@sss.pgh.pa.us> <24861.1162276496@sss.pgh.pa.us> <20061031101314.R83230@megazone.bigpanda.com> <14059.1162363105@sss.pgh.pa.us> <1162463264.3587.281.camel@silverbirch.site> Comments: In-reply-to "Simon Riggs" message dated "Thu, 02 Nov 2006 10:27:44 +0000" Date: Thu, 02 Nov 2006 10:51:25 -0500 Message-ID: <16897.1162482685@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/12 X-Sequence-Number: 26664 "Simon Riggs" writes: > We have namespaces to differentiate between two sources of object names, > so anybody who creates a schema where MyColumn is not the same thing as > myColumn is not following sensible rules for conceptual distance. I'd agree that that is not a good design practice, but the fact remains that they *are* different per spec. > Would be better to make this behaviour a userset > switchable between the exactly compliant and the more intuitive. That's certainly not happening --- if you make any changes in the semantics of equality of type name, it would have to be frozen no later than initdb time, for exactly the same reasons we freeze locale then (hint: index ordering). regards, tom lane