The library used to parse URLs is not spec-compliant

[not-my-profile]

It took me more than an hour to get data_source_name to work which was very frustrating because for everything I tried I just kept getting a different error, all for URLs that should work.

While xo/dburl delegates the opening of the connection to lib/pq it does not use the ParseURL function from lib/pq and instead has it's own URL handling logic, which doesn't support many URLs supported by both libpq and lib/pq. This is already quite bad but what's worse is that the format that you have to use to make it work is not even a valid URL as per the RFC because xo/dburl implements its own non-compliant URL parsing logic on top of net/url. Debugging this is further complicated by the Parse function from xo/dburl yielding different results depending on the existence of paths on the filesystem. I reported these issues as xo/dburl#46 and xo/dburl#45, all of which were immediately closed because the implementation is as the author intends it to be. While they do say that they'll accept any well-written PR, I'm not interested in contributing to a project that closes valid bug reports.

Looking at the issue tracker here I am not the first person to run into these pitfalls and I won't be the last one. dburl.Open calls sql.Open, which accepts a driverName and dataSourceName. I think it would be better if sql_exporter let its users directly specify both, side-stepping the pitfalls of xo/dburl.

sql_exporter currently confuses semantics a bit by having users specify a URL as data_source_name (URLs aren't DSNs: xo/dburl tries to convert URLs to DSNs). So my suggestion would be to deprecate URLs in data_source_name but continue to support them for the next release but logging a warning that they're deprecated and you should switch your config to driver: "%s", data_source_name: "%s" (where %s are the driver and DSN currently parsed by xo/dburl). This warning would be printed if the data_source_name starts with a URL scheme. What do you think?