Would it be feasible to support attribute values being specified via a query's parameter bindings?
Idea
I'd like to support prepared statements like the following (and stay within the sqlcommeter spec):
LOG: execute my-demo-stmt: SELECT * FROM FOO WHERE ID = $1 /*application='app-1', traceparent=$2*/
DETAIL: parameters: $1 = 1234, $2 = '00-5bd66ef5095369c7b0d1f8f4bd33716a-c532cb4098ac3dd2-01'
This would necessitate an extension to sqlcommeter spec. Something like:
FIELD ::= <SERIALIZED_KEY>=<VALUE>
VALUE ::= <SERIALIZED_VALUE> | <PARAM_NUM>
PARAM_NUM ::= $[0-9]+
Motivation
My objective is to enable the performance benefits of prepared statements, whilst still being able to use a unique per-query traceparent.
In Postgres, it is technically possible to prepare and execute a statement like the example above. (The $2 parameter is simply unused by the query planner, but still appears in the statement log.) I am exploring adding this support to DataDog/dd-trace-go's SqlCommeter.
Would this feature in the spec be generally useful?
Would it be feasible to support attribute values being specified via a query's parameter bindings?
Idea
I'd like to support prepared statements like the following (and stay within the sqlcommeter spec):
This would necessitate an extension to sqlcommeter spec. Something like:
Motivation
My objective is to enable the performance benefits of prepared statements, whilst still being able to use a unique per-query
traceparent.In Postgres, it is technically possible to prepare and execute a statement like the example above. (The
$2parameter is simply unused by the query planner, but still appears in the statement log.) I am exploring adding this support to DataDog/dd-trace-go'sSqlCommeter.Would this feature in the spec be generally useful?