Re: [HACKERS] Cluster wide option to control symbol case folding - Mailing list pgsql-hackers

From Lewis, Ian \(Microstar Laboratories\)
Subject Re: [HACKERS] Cluster wide option to control symbol case folding
Date
Msg-id ACF85C502E55A143AB9F4ECFE960660A172832@mailserver2.local.mstarlabs.com
Whole thread Raw
In response to [HACKERS] Cluster wide option to control symbol case folding  ("Lewis, Ian \(Microstar Laboratories\)" <ilewis@mstarlabs.com>)
Responses Re: [HACKERS] Cluster wide option to control symbol case folding  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Cluster wide option to control symbol case folding  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas [mailto:robertmhaas@gmail.com] wrote:
> The issue is, rather, that every extension written for
> PostgreSQL, whether in or out of core, needs to handle this issue and
> every general-purpose client tool (pgAdmin, etc.) needs to be aware of
> it. ....

I can see the accuracy of all of the points you make here. And, I
definitely had not thought through the side effects on support tools and
third party libraries of implementing such modal behavior on the server
when I originally asked my question. I did not even understand the
ramifications of upper case folding on the server until Tom pointed out
the earlier conversations on the subject (in my defense, I was not
confused enough to think I had thought through all the effects of a
fundamental change to language recognition based on writing one e-mail
message).

A fully case sensitive mode, leaving the server catalogs all in lower
case, which is what we would really like to have for our use, still
looks pretty easy to implement on the server. And, it would at least
behave consistently with the lower case folding mode if one quoted all
identifiers, unlike a case preserving, case insensitive mode.

One idea, which would likely be harder to implement on the server, but
that would have less impact on third party tools and libraries, would be
to configure case folding on a session basis. There would have to be
some means to configure a session for the case folding your application
wants to see. And, the general default would have to be the current
PostgreSQL behavior so that an application that was designed for current
behavior would never see a change.

While not quite obvious to me how one would implement this for all
client environments, it would make such a feature more useful if it
included a means to make the configuration outside of the scope of an
application itself so that one could give an application over which one
has no control the behavior it expects. That is, provide a means to
configure a specific application's session default behavior on the
client. But, provide no means to configure the server's general default
behavior so that the server itself is never modal with respect to case
folding. Only the client session is modal.

It is pretty easy to see the pain of adding symbol case folding modes.
On the other hand, there is no way to know exactly the gain (or loss) in
adoption to providing alternate case folding. So, you have one fact (the
pain) and one speculation (the gain). I can see that makes deciding
whether this is a good or bad idea for the project not at all easy.

Anyhow, I appreciate the time you, and others, have taken to explain
your thinking and the impacts of adding modal case folding to the
server.

Ian Lewis (www.mstarlabs.com)



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Measuring replay lag
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)