Case normalization in db.name, db.collection.name, db.operation.name?

[trask]

Should we say anything about case normalization when capturing db.name, db.collection.name, db.operation.name? Or just say to capture the case as it is presented by the library or user query?

[pyohannes]

Given that for example in MySQL table names can be case-sensitive under some circumstances, I'd say it makes sense to capture the casing as is and not alter it.

[gregkalapos]

Looked into this a bit, most database systems can operate in case-sensitive mode, even if they are case-insensitive by default. This is a good article.

For table names:

• PostgreSQL: case-insensitive by default, but table names in double quotation marks (") are case sensitive
• MySQL: depends on the OS by default and you can change it- details above
• MS SQL Server: case-insensitive by default, but can be changed by modifying the collation setting

Only downside of capturing as is I can come up with is when the DB is case-insensitive (MyTable and mytable are indeed the same), but the observability backend that stores the telemetry data is case-sensitive and users mix casing in queries - in that case filtering, grouping, aggregating such data will be problematic. But overall I think the advantage of properly handling case-sensitive cases outweighs this hypothetical scenario. So I'd also go with capturing as is.

[trask]

how about adding this language for db.namespace, db.operation.name and db.collection.name?

It is RECOMMENDED to capture the value as provided by the application without attempting to do any case normalization.

[trask]

We could also say nothing, I think the default when normalization is not mentioned in semconv should be to NOT normalize.