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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
