Better guidance on semantic conventions for database client call span names in case of missing information

[Brar]

What are you trying to achieve?
When tracing an activity from Npgsql (.NET Database provider for PostgreSQL) we want to set a valid span name according to the semantic conventions for database client calls without having to parse the database statement on the client side and without having to guess (or rather infer from our knowledge on the current default behavior of PostgreSQL) information that we don't have when issuing a database client call.

What did you expect to see?
Guidance on creating a valid span name in cases where all three of db.operation, db.name and db.sql.table are not available to the database client.
Per discussion following npgsql/npgsql#4757 (comment) we think that it is probably pretty safe to infer the database name from our knowledge on PostgreSQL's default behavior but we may still want to research/discuss what good alternatives could be.

Additional context.
https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/database/
npgsql/npgsql#4757 (comment)

[jsuereth]

The specification already states:

When it’s otherwise impossible to get any meaningful span name, db.name or the tech-specific database name MAY be used.

Is this a viable option here? Just write "postgresql" for the span name here.

While (for use abilities sake) I'd suggest perhaps trying to find a way (without parsing) to pull in additional information, perhaps via passing data when it is available in Context, you're still specification compliant setting the span name to "postgresql" or "npgsql"

[trask]

@open-telemetry/technical-committee can you move this to https://github.com/open-telemetry/semantic-conventions?

[trask]

When it’s otherwise impossible to get any meaningful span name, db.name or the tech-specific database name MAY be used.

Looking back at where this language was introduced (open-telemetry/opentelemetry-specification#575), I think "tech-specific database name" meant:

• db.cassandra.keyspace
• db.hbase.namespace

which were alternatives to db.name until open-telemetry/opentelemetry-specification#1973 removed them and consolidated on db.name.

Recommending falling back to db.system (which is what @jsuereth suggests above) sounds like it could be a good option.