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 58210D1EC10; Fri, 23 Apr 2004 17:16:16 -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 63488-05; Fri, 23 Apr 2004 17:16:15 -0300 (ADT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id C1E1BD1EB43; Fri, 23 Apr 2004 17:16:13 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 5D1AB353BF; Fri, 23 Apr 2004 13:16:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 5756435099; Fri, 23 Apr 2004 13:16:15 -0700 (PDT) Date: Fri, 23 Apr 2004 13:16:15 -0700 (PDT) From: Stephan Szabo To: Shachar Shemesh Cc: Robert Treat , Dennis Bjorklund , Bruce Momjian , PostgreSQL-development , PostgreSQL advocacy Subject: Re: [HACKERS] What can we learn from MySQL? In-Reply-To: <40897131.6020902@shemesh.biz> Message-ID: <20040423130701.K21905@megazone.bigpanda.com> References: <1082735128.22969.1106.camel@camel> <20040423094236.J17459@megazone.bigpanda.com> <40897131.6020902@shemesh.biz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/166 X-Sequence-Number: 4138 On Fri, 23 Apr 2004, Shachar Shemesh wrote: > Stephan Szabo wrote: > > >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. > > > > > That's not the migration path I was thinking of. > > What I was thinking of was: > 1. Have a setting, probably per-session. Per database works too. > 2. Aside from the folder upper and folder lower, have a third option. > This is "fold upper, if fails, fold lower. If succeeds, issue a > warning". This should allow programs that rely on the folding (such as > initdb) to be debugged during the transition period. If you can do this in a clean fashion without tromping all around the code, that'd be reasonable, however, istm that you'd need to either pre-fold both directions from the given identifier string and pass an extra copy around or pass the original identifier and its quoted status and fold on use. I think either of these are likely to be very intrusive for what essentially amounts to a transitional feature. In addition, I'm not sure that this would always work in any case, since some of those usages may be quoted identifiers that were once generated from a case-folded string (for example, looking up a name in the catalogs and quoting it).