PostgreSQL: Restore role to its original value between migrations instead of resetting it #2035
Which version and edition of Flyway are you using?
If this is not the latest version, can you reproduce the issue with the latest one as well?
(Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Which database are you using (type & version)?
Which operating system are you using?
What did you do?
(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)
I need to be able to run 'set role $rolename' for all flyway migrations, including the initial metadata table creation. This is to ensure that the created objects are owned by the 'correct' user. We are using vault for database credential management, so the user running the migrations is dynamic and will change over time, leading to inconsistent ownership of objects.
What did you expect to see?
Possibly a flyway configuration option, or callback support to call 'set role'. I'm not sure if there's a callback which is run before the initial metadata table creation?
What did you see instead?
I saw a few issues related to this, including a call to 'RESET ROLE' which appears to be conflicting with my attempts to use connectInitSql on the pool, or the beforeMigration callback.
The text was updated successfully, but these errors were encountered:
I am not sure a dedicated setting would be pulling its conceptual weight at this point, especially considering the easy workaround available.
But the future will tell. If this does prove to be a major pain point down the road, we'll gladly reconsider this decision.
No, as this would potentially produce different results. For example if V1 changes the role and V2 does not then running V1 + V2 together will produce a different result than running V1 and then later V2.
Yes, but if a user is messing with roles in the migration, then they should ensure that they do the reset, no?
By the same argument, if I connect with user1 and run v1 + v2, that produces a different result than when I connect with user1 and run v1 and then connect with user2 and run v2.
I am starting to warm for the option of adding a
More background info: https://dba.stackexchange.com/questions/77704/proxy-authentication-for-postgesql
I am starting to think that an even better solution would be to expose the initSqls property of the data source to all clients. This would allow for a generic way to do things like set role before any other Flyway code runs.
This should then be combined with replacing the reset role calls with an initial call to read the current user and individual calls before each migration to reset the current user to the one we read before.