Can't use UNIX socket for postgres connection about sql_exporter

[caseyandgina]

Thank you for the information. Though surprising behavior, it is working now, so I’ll close this.

[caseyandgina]

Hmm, surprisingly, not urlencoding the socket path works, e.g. data_source_name: 'postgres://app_sql_exporter@/run/postgresql:5432/postgres'

[burningalchemist]

Hi @caseyandgina,

There's no need to encode the DSN as it needs to be parsed by dburl library.

We only might need to encode the password if it contains special characters.

[caseyandgina]

I was thinking it was due to the dburl library, but this is nonstandard behavior. Usually, the extra unescaped slashes in the hostname portion of the URI break things, so I’ve long been accustomed to having to escape these in postgres:// URIs.

For example:

$ psql "postgres://postgres@/run/postgresql/postgres"
psql: error: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: FATAL:  database "run/postgresql/postgres" does not exist

$ psql "postgres://postgres@%2Frun%2Fpostgresql/postgres"
psql (16.3 (Ubuntu 16.3-1.pgdg24.04+1))
Type "help" for help.

postgres=# 

It also makes reading the URI's unclear. I'd rather be able to specify all the connection parameters separately in the YML rather than using a URI, but that doesn't seem to be a possibility presently. Or keyword/value syntax like this, which would require specifying the driver as a separate parameter:

$ psql "user=postgres host=/run/postgresql dbname=postgres"
psql (16.3 (Ubuntu 16.3-1.pgdg24.04+1))
Type "help" for help.

postgres=#

[burningalchemist]

As mentioned above, this project historically relies on DSN and lately 'dburl' (https://github.com/xo/dburl) parsing library to handle connection strings for different databases, protocols, transports and parameters. It provides a unified way to connect to all the supported databases with minimal effort, and seems sufficient for the project goals. Please have a look at the dependency by the posted link for more details on parsing the strings. 👍

What's also possible is you may use environment variables as placeholders in the DSN string and interpolate parts of it as needed.

For now there is no intention to change the connection configuration anytime soon.