Message-ID: <45727D9D.6080409@kensystem.com>
Date: Sun, 03 Dec 2006 00:32:45 -0700
From: Ken Johanson <pg-user@kensystem.com>
Reply-To: ken@kensystem.com
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-sql@postgresql.org
Subject: Re: [HACKERS] Case Preservation disregarding case
References: <200610301928.51255.beauh@bluefrogmobile.com>
	<23177.1162265010@sss.pgh.pa.us>
	<EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
	<45712E31.1030004@kensystem.com> <20061202133556.GC26365@svana.org>
	<457199E4.3010401@kensystem.com> <4571A3AF.6070608@zigo.dhs.org>
	<4571AE66.7050304@kensystem.com> <4571B392.6020303@zigo.dhs.org>
	<4571C133.1060200@kensystem.com> <20061202201822.GD26365@svana.org>
	<45725923.7010500@kensystem.com> <13344.1165125338@sss.pgh.pa.us>
In-Reply-To: <13344.1165125338@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Ken Johanson <pg-user@kensystem.com> writes:
> 
>> -*If* the option to turn on case-insenetive behavior were selectable at 
>> the DB or session level, the existing apps could continue to use the 
>> case sensitve mode and be completely unaffected.
> 
> Ken, you clearly fail to understand the point being made above.  This is
> not something that is "selectable at the session level".  It won't work
> from either a functional or performance perspective.
> 

Tom,

re: "clearly fail to understand": I know it's not currently selectable 
at the session-level. My proposal (quote):

*If* the option ... were selectable

was to make them selectable -- this and another item that I'd proposed 
in the past (The proposal for 'standard_conforming_strings' at the 
session level was a step *toward* spec without harming existing apps). 
Having to set standard_conforming_strings globally for example, is a 
problematic setup for shared servers (ISPs etc).

A session configurable strategy is a huge feature to have in shared 
environments. (BTW that strategy is both "functional and performing" for 
Mysql -- several SQL conformance items can be config'd per connection).

> ...proposals that involve moving away from the SQL spec rather than
> closer to it; and that's what you're asking us to do.

If I ever proposed changing any *default* (spec) behavior, it was 
inadvertent or a mistake. (prob. in making my argument that case-insens 
does more harm that good for new PG users).

Of course adhering to spec is desirable, and if that mode of operation 
remains *supported by default*, good. Adding per-connection or per-db 
'quirks mode' (in the case of plug-in apps already built as case-insens 
is innocuous).. that's a useful thing.

Put another way how many places is PG *deviating* from spec just by 
providing conveniences -- would users revolt if those were dropped? For 
compatibility, whether with old PG or Mysql (which is case-preserving 
but case insens.), we NEED them. Not as a default behavior per se, but 
as a per-session option.


Best,
Ken