sqlalchemy: db.operation.name carries the database name as well as the operation

_operation_name in the SQLAlchemy instrumentation returns the operation token joined to the database name, and that same string is used for two different consumers.

At engine.py:377 it becomes the span name, which is correct, since the span convention is <operation> <target>.

At engine.py:348 it is passed to _set_db_operation, which writes it verbatim to db.operation.name and to the legacy db.operation (_semconv.py:612). Stable semconv defines db.operation.name as the name of the operation being executed, and the database name is not part of that.

The path, for a sqlite engine:

engine = create_engine("sqlite:///:memory:")
SQLAlchemyInstrumentor().instrument(engine=engine, tracer_provider=tp)
engine.connect().execute(text("SELECT 1 + 1"))
# db.operation.name gets "SELECT :memory:"; semconv wants "SELECT"

This is on main today and is independent of #4943, which only stops an IndexError in the same function and leaves this behaviour alone. Filing it here as @xrmx asked on that PR.

Start in engine.py at lines 348 and 377, then inspect _semconv.py:612 to understand how the operation value reaches span naming and database attributes. Exercise the SQLite example and verify that the span retains the target while db.operation.name and legacy db.operation contain only the operation token.