Comment 20 for bug 1538011

After discussing on IRC and thinking about it, I understand the situation better in that the only way we could allow case sensitive metadata keys (that is, let users set whatever they want) is if we rewrite our existing metadata key queries to do a preliminary read-only query first (no more SELECT FOR UPDATE, IN, etc), filter in Python, and then act upon an exactly matching record. It also requires that we not have a unique constraint on the column. We would be constrained in the way we could query metadata keys and set column constraints and it's complex and error-prone, for not a lot of gain.

My primary concern was the idea of casefolding the keys. With the suggestion of raising an error if an API caller attempts to set a non-lowercase key, my concern is addressed.

As you mentioned on the review, I think we can add the validation and leave the backend as-is. That way previously set CamelCase keys continue to work and we avoid future problems.