Date: Fri, 23 Apr 2004 09:46:18 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Robert Treat <xzilla@users.sourceforge.net>
Cc: Dennis Bjorklund <db@zigo.dhs.org>, Shachar Shemesh <psql@shemesh.biz>,
	Bruce Momjian <pgman@candle.pha.pa.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PostgreSQL advocacy <pgsql-advocacy@postgresql.org>
Subject: Re: [HACKERS] What can we learn from MySQL?
In-Reply-To: <1082735128.22969.1106.camel@camel>
Message-ID: <20040423094236.J17459@megazone.bigpanda.com>
References: <Pine.LNX.4.44.0404231117270.4551-100000@zigo.dhs.org>
	<1082735128.22969.1106.camel@camel>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 23 Apr 2004, Robert Treat wrote:

> On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
> > On Fri, 23 Apr 2004, Shachar Shemesh wrote:
> >
> > > When I ask about non-standard complience of Pg (turning unquoted
> > > identifiers to lowercase instead of uppercase, violating the SQL
> > > standard, and requring an expensive rewrite of clients), and I get the
> > > answer "uppercase is ugly", I think something is wrong.
> >
> > I would love if someone fixed pg so that one can get the standard
> > behaviour. It would however have to be a setting that can be changed so we
> > are still backward compatible.
> >
> > > that even if I write a patch to start migration, I'm not likely to get
> > > it in.
> >
> > Just changing to uppercase would break old code so such a patch should not
> > just be commited. But would people stop a patch that is backward
> > compatible (in the worst case a setting during initdb)? I'm not so sure
> > they will.
> >
>
> 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.