From: Ken Johanson <pg-user@kensystem.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-sql@postgresql.org
Subject: Re: [HACKERS] Case Preservation disregarding case
Date: Sun, 03 Dec 2006 00:32:45 -0700
Message-ID: <45727D9D.6080409@kensystem.com> (raw)
In-Reply-To: <13344.1165125338@sss.pgh.pa.us>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pg-user@kensystem.com, tgl@sss.pgh.pa.us
Subject: Re: [HACKERS] Case Preservation disregarding case
In-Reply-To: <45727D9D.6080409@kensystem.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox