Open Stack

On 08/13/2018 11:56 AM, Chris Friesen wrote:
> On 08/13/2018 08:26 AM, Jay Pipes wrote:
>> On 08/13/2018 10:10 AM, Matthew Booth wrote:
> 
>>> I suspect I've misunderstood, but I was arguing this is an anti-goal.
>>> There's no reason to do this if the db is working correctly, and it
>>> would violate the principal of least surprise in dbs with legacy
>>> datasets (being all current dbs). These values have always been mixed
>>> case, lets just leave them be and fix the db.
>>
>> Do you want case-insensitive keys or do you not want case-insensitive 
>> keys?
>>
>> It seems to me that people complain that MySQL is case-insensitive by 
>> default
>> but actually *like* the concept that a metadata key of "abc" should be 
>> "equal
>> to" a metadata key of "ABC".
> 
> How do we behave on PostgreSQL?  (I realize it's unsupported, but it 
> still has users.)  It's case-sensitive by default, do we override that?
> 
> Personally, I've worked on case-sensitive systems long enough that I'd 
> actually be surprised if "abc" matched "ABC". :)

You have worked with case-insensitive systems for as long or longer, 
maybe without realizing it: All URLs are case-insensitive.

If a user types in http://google.com they go to the same place as 
http://Google.com because DNS is case-insensitive [1] and has been since 
its beginning. Users -- of HTTP APIs in particular -- have tended to 
become accustomed to case-insensitivity in their HTTP API calls.

This case is no different, IMHO.

Best,
-jay

[1] https://tools.ietf.org/html/rfc4343#section-4