[9.x] Alternative database name in Postgres DSN, allow pgbouncer aliased databases to continue working on 9.x #43542
+21
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I encountered this issue that prevented migrations from running after upgrading to Laravel 9: #43536 (
php artisan migrate
fails after attempting to createmigrations
table that already exists)It is caused by my (fringe?) pgbouncer setup + the introduction of the
table_catalog
parameter into queries in 9.x via #35530Here's a repo to reproduce the issue: https://github.com/AlbinoDrought/l9-pgsql-pgbouncer-alias
When using pgbouncer, the "database" name used to connect is just a pool name - pgbouncer can connect to a differently-named database behind the scenes. As an example, a
sample_app
database could have asample_app_background
pool and asample_app_web
pool. In Laravel you would specify['database' => 'sample_app_background']
or['database' => 'sample_app_web']
to connect.In Laravel <9, the
database
config var does not appear to be referenced by thePostgresConnector
after DSN generation. The above pgbouncer setup works transparently.In Laravel 9, the
database
config var is referenced duringPostgresConnector
DSN generation,hasTable
, andgetColumnListing
. The above pgbouncer setup now causes issues.If we're connected to the
sample_app_web
pool,hasTable
andgetColumnListing
queryinformation_schema
about thesample_app_web
database, but that database doesn't exist. This causeshasTable
to always returnfalse
which is problematic during migrations. We wanthasTable
andgetColumListing
to query about thesample_app
database instead.I don't know what
getColumnListing
is used for (something about guarded attributes?) but it also references thedatabase
config var, possibly outside of migrations.This proposed fix allows specifying a different database name used only during
PostgresConnector
DSN generation. The pool name should be specified here. I currently chose the config namedatabase_connect
but don't really like it. Users would specify a config like['database' => 'sample_app', 'database_connect' => 'sample_app_web']
to continue using a pgbouncer setup like above.I'm not sure how common this kind of setup is. If this change isn't wanted upstream, it can be accomplished by overriding PostgresConnector in a third-party package (this is what I'm currently doing).
Thanks!