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 9E810D1B98D; Sat, 24 Apr 2004 02:58:19 -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 47098-02; Sat, 24 Apr 2004 02:58:19 -0300 (ADT)
Received: from joeconway.com (66-146-172-86.skyriver.net [66.146.172.86])
	by svr1.postgresql.org (Postfix) with ESMTP
	id 45050D1B8B7; Sat, 24 Apr 2004 02:58:17 -0300 (ADT)
Received: from [192.168.4.3] (account jconway HELO joeconway.com)
	by joeconway.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 1535618; Fri, 23 Apr 2004 22:52:13 -0700
Message-ID: <408A019B.4060307@joeconway.com>
Date: Fri, 23 Apr 2004 22:56:43 -0700
From: Joe Conway <mail@joeconway.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>,
	Shachar Shemesh <psql@shemesh.biz>,
	Robert Treat <xzilla@users.sourceforge.net>,
	Dennis Bjorklund <db@zigo.dhs.org>, 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?
References: <Pine.LNX.4.44.0404231117270.4551-100000@zigo.dhs.org>
	<1082735128.22969.1106.camel@camel>
	<20040423094236.J17459@megazone.bigpanda.com>
	<40897131.6020902@shemesh.biz>
	<20040423130701.K21905@megazone.bigpanda.com>
	<20040423132913.X22334@megazone.bigpanda.com>
	<7305.1082779876@sss.pgh.pa.us>
In-Reply-To: <7305.1082779876@sss.pgh.pa.us>
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/179
X-Sequence-Number: 4151

Tom Lane wrote:
> Aside from the reality that apps aren't very consistent about their
> quoting behavior, the fly in this ointment is that whenever you query
> the database catalogs you will see the stored spelling of the name.
> So apps that rely on seeing the same spelling in the catalog that they
> entered could break.  (In practice this doesn't seem to be as big a
> problem as the sloppy-quoting-behavior issue, though.)

Shouldn't apps only really be querying the information schema if they're 
expecting spec compliant behavior? If so, a GUC variable with an access 
function ought to be enough to get up or down casing as desired, I'd think.

Joe