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