Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 857269FB3B1;
	Tue, 31 Oct 2006 14:07:01 -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 85856-06; Tue, 31 Oct 2006 18:06:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [125.62.87.134])
	by postgresql.org (Postfix) with ESMTP id DDCFC9FB3AD;
	Tue, 31 Oct 2006 14:06:52 -0400 (AST)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1Gey05-0002Ix-B8; Wed, 01 Nov 2006 05:06:13 +1100
Date: Tue, 31 Oct 2006 19:06:13 +0100
From: Martijn van Oosterhout <kleptog@svana.org>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Chuck McDevitt <cmcdevitt@greenplum.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	beau hargis <beauh@bluefrogmobile.com>, pgsql-sql@postgresql.org,
	pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Case Preservation disregarding case
Message-ID: <20061031180613.GB29338@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <200610271623.37525.beauh@bluefrogmobile.com>
	<1162003132.687.8.camel@pampa>
	<200610301928.51255.beauh@bluefrogmobile.com>
	<23177.1162265010@sss.pgh.pa.us>
	<EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
	<24861.1162276496@sss.pgh.pa.us>
	<EB48EBF3B239E948AC1E3F3780CF8F88012F89F8@MI8NYCMAIL02.Mi8.com>
	<45478E22.8060805@dunslane.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu"
Content-Disposition: inline
In-Reply-To: <45478E22.8060805@dunslane.net>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200611/60
X-Sequence-Number: 26712


--TRYliJ5NKNqkz5bu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 31, 2006 at 12:55:46PM -0500, Andrew Dunstan wrote:
> To this you propose, as I understand it, to have a fourth possibility=20
> which would be spec compliant for comparison purposes but would label=20
> result set columns with the case preserved name originally used (or=20
> would you use the casing used in the query?).

The big issue I see with this is that it would break PQfname on the
client end, since that's case sensetive too. Most client languages are,
so you really are between a rock and a hard place.

Making PQfname case-insensetive also screws up in Tom's example.

One way to appraoch this is to consider this a setting of the collation
of the name datatype. If a case-insensetive collation is selected at
initdb time, then Tom's example would indeed fail, but that's a choice
someone made. Problem being, you'd have to export that choice to
clients to make PQfname work, and that's going to messy.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--TRYliJ5NKNqkz5bu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFR5CVIB7bNG8LQkwRAjdTAJ485foIoYgoWsm1wvuvdFjCHr3Y1QCfUD/5
LMIyztXUqxKk3EGdPyG26Fs=
=J0qa
-----END PGP SIGNATURE-----

--TRYliJ5NKNqkz5bu--