Added support for parsing pool_mode at the end of the database URL using a slash.

[rene-rene-rene]

Added support for parsing pool_mode at the end of the database URL using a slash.

DATABASE_URL="postgres://user:pass@postgres-host/database/session

[jflambert]

@rene-rene-rene Is setting pool_mode as part of the connection string idiomatic? If we already have POOL_MODE why do we need an alternative?

[rene-rene-rene]

This will allow fine-grained configuration of different pool types via an environment variable:

DATABASE_URLS=postgres://user:password@db-host/postgres/session,postgres://user:password@db-host/db2/transaction

which will then be transformed into:

[databases]
postgres = host=db-host port=5432 auth_user=user pool_mode=session
db2 = host=db-host port=5432 auth_user=user pool_mode=transaction

It might be useful.

[jflambert]

This will allow fine-grained configuration of different pool types via an environment variable:

DATABASE_URLS=postgres://user:password@db-host/postgres/session,postgres://user:password@db-host/db2/transaction

which will then be transformed into:

[databases] postgres = host=db-host port=5432 auth_user=user pool_mode=session db2 = host=db-host port=5432 auth_user=user pool_mode=transaction

It might be useful.

That's a key explanation, I forgot about this multiple DB config option.

I'm just unsure how I feel about "augmenting" a normally cast-in-stone database connection string format. Would this impact any parameters passed with ?, can you validate?

[rene-rene-rene]

Good point, and I think you're right to be cautious about augmenting the connection string format. I want to look into this properly before we move forward — in particular how the path-based parsing interacts with query parameters passed via ?. Let me validate that and I'll get back to you shortly with findings.

[rene-rene-rene]

Thanks for the feedback — you were right to be wary of augmenting the connection string format.

I've reworked the approach. Instead of encoding pool_mode as an extra path segment (/dbname/pool_mode), per-database options are now read from the URL query string, which keeps the URL libpq-compatible and lets the path mean the database name only:

DATABASE_URL="postgres://user:pass@host:5432/mydb?pool_mode=transaction"

Every key=value pair after ? is appended verbatim to the generated [databases] entry, so any number of options can be combined:

DATABASE_URL="postgres://user:pass@host:5432/mydb?pool_mode=transaction&pool_size=20&min_pool_size=5"

Parameter names are intentionally not validated — they're passed to pgbouncer as-is. This keeps the mechanism generic (any current or future per-db option works without code changes) and is consistent with how the rest of the connection string is already trusted. Using invalid names is the user's responsibility.

This also addresses your concern about ? parameters: the path and the query string are now split explicitly, so query params no longer leak into the database name.