Is your feature request related to a problem?
Currently, the pool.name attribute in Npgsql metrics can only be customized by explicitly calling NpgsqlDataSourceBuilder.Name = "CustomersDB".
However, in many integration scenarios (like standard ASP.NET Core configuration or older legacy migrations), we initialize connections or data sources directly using a Connection String. In these cases, there is no way to provide a human-readable name for the pool, leading to metrics that are hard to distinguish in monitoring dashboards.
Describe the solution you'd like
Add a new keyword to the Connection String (e.g., Pool Name or Metrics Pool Name).
When the NpgsqlConnectionStringBuilder parses this keyword, it should be used to populate the underlying DataSource name, which in turn reflects in the pool.name metric tag.
Example:
var connectionString = "Host=localhost;Database=prod;Pool Name=CustomersDB";
// This should automatically set the pool.name tag to 'CustomersDB'
Describe alternatives you've considered
The current alternative is to manually use NpgsqlDataSourceBuilder:
var dataSource = new NpgsqlDataSourceBuilder(connectionString)
{
Name = "CustomersDB"
}.Build();
While this works, it adds boilerplate code and is not possible when the underlying framework/library only accepts a connection string and handles the DataSource creation internally.
Additional context
Providing this via the connection string aligns with the "Configuration as Code" philosophy and makes telemetry setup more transparent for DevOps teams.
Is your feature request related to a problem?
Currently, the pool.name attribute in Npgsql metrics can only be customized by explicitly calling
NpgsqlDataSourceBuilder.Name = "CustomersDB".However, in many integration scenarios (like standard ASP.NET Core configuration or older legacy migrations), we initialize connections or data sources directly using a Connection String. In these cases, there is no way to provide a human-readable name for the pool, leading to metrics that are hard to distinguish in monitoring dashboards.
Describe the solution you'd like
Add a new keyword to the Connection String (e.g., Pool Name or Metrics Pool Name).
When the NpgsqlConnectionStringBuilder parses this keyword, it should be used to populate the underlying DataSource name, which in turn reflects in the pool.name metric tag.
Example:
Describe alternatives you've considered
The current alternative is to manually use NpgsqlDataSourceBuilder:
While this works, it adds boilerplate code and is not possible when the underlying framework/library only accepts a connection string and handles the DataSource creation internally.
Additional context
Providing this via the connection string aligns with the "Configuration as Code" philosophy and makes telemetry setup more transparent for DevOps teams.