Feature request: wildcard / catch-all [[databases]] entry for multi-tenant deployments

[dakar-xm]

Use case

I'd like to use PgDog as a pooler in front of a multi-tenant Postgres cluster (one primary + several read replicas). The main draw of PgDog for us is transaction pooling combined with automatic read/write splitting across replicas.

The cluster hosts a large and changing set of databases: tenants are onboarded and offboarded continuously, and each onboarding creates several databases. So the set of database names is not known ahead of time and changes at runtime.

Current behavior

Every database has to be enumerated explicitly in [[databases]] — there's no wildcard or catch-all. From the source:

• Database.name is an exact String (pgdog-config/src/database.rs), matched exactly.
• Passthrough auth does register users dynamically at connect time (add() in pgdog/src/backend/databases.rs), but each user's database must still reference a pre-declared [[databases]] entry.

For a multi-tenant topology this means generating and reloading a set of [[databases]] entries (one per database × primary + each replica) for every tenant, and keeping all pooler instances in sync as tenants come and go.

For comparison, PgBouncer supports a * fallback database (* = host=…, with dbname defaulting to the client-requested name), which handles this case with no per-database config. But PgBouncer doesn't do the replica read/write routing that's the reason I want PgDog.

Requested feature

A wildcard / catch-all [[databases]] entry — conceptually the natural extension of what passthrough already does for users. For example:

[[databases]]
name = "*"                 # matches any requested database name
role = "primary"
host = "primary.example.com"
# database_name defaults to the client-supplied name

[[databases]]
name = "*"
role = "replica"
host = "replica-1.example.com"
# ...one per replica

Behavior: any requested database name is routed to this cluster (with database_name defaulting to the name the client connected with), and the usual read/write splitting + replica load balancing applies. Pools would be created lazily per (user, database), the same way passthrough already creates them for users.

Questions

1. Is there an existing way to achieve this today that I've missed — a default database, a plugin hook, or a recommended admin ADD workflow for dynamic tenant onboarding/offboarding?
2. If not, would a wildcard database entry be something you'd consider adding? Happy to test it against a real multi-tenant workload.