I have found these related issues/pull requests
Relates to boringSQL/dryrun#11
Description
libx does not support libpq service files. It's a feature all tooling in Postgres uses and provides nice abstraction for connection URLs. You can simply declare the service intention service=my_service and have rest of the stack.
I'm happy to try to implement it, but would like to confirm couple of things before starting (not to waste time).
What path of implementation makes sense to get started with
- resolve service to URL (i.e. build postgresql://...)
- Resolve to PgConnectOptions
- Anything else
There are three ways how libpq accepts the input
- PGSERVICE=my_service (env var)
- database url:
DATABASE_URL: service=my_service sslmode=require
- param in URL:
postgresql:///?service=my_service
Is there preferred way to tackle in initial implementation?
And does it also make sense to include .pgpass support?
Prefered solution
Add native libpq service file support to sqlx-postgres, so PgConnectOptions resolves service= references the same way libpq and every other Postgres client library already does.
Is this a breaking change? Why or why not?
Not a breaking change. Additive changes only.
I have found these related issues/pull requests
Relates to boringSQL/dryrun#11
Description
libx does not support libpq service files. It's a feature all tooling in Postgres uses and provides nice abstraction for connection URLs. You can simply declare the service intention
service=my_serviceand have rest of the stack.I'm happy to try to implement it, but would like to confirm couple of things before starting (not to waste time).
What path of implementation makes sense to get started with
There are three ways how libpq accepts the input
DATABASE_URL: service=my_service sslmode=requirepostgresql:///?service=my_serviceIs there preferred way to tackle in initial implementation?
And does it also make sense to include
.pgpasssupport?Prefered solution
Add native libpq service file support to sqlx-postgres, so PgConnectOptions resolves service= references the same way libpq and every other Postgres client library already does.
Is this a breaking change? Why or why not?
Not a breaking change. Additive changes only.