Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PostgreSQL: Flyway uses "public" schema instead of current_schema when search_path starts with $user #1926

Closed
ghost opened this issue Feb 14, 2018 · 4 comments

Comments

@ghost
Copy link

@ghost ghost commented Feb 14, 2018

What version of Flyway are you using?

5.0.7

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API

What database are you using (type & version)?

PostgreSQL 9.6

What operating system are you using?

Ubuntu 16.04

What did you do?

Migrate or baseline on a connection where search_path starts with $user.

This affects all migration actions due to the way ´PostgreSQLConnection.getFirstSchemaFromSearchPath´ works.

What did you expect to see?

Metadata table and application's schema objects are created in the current_schema which is also the name of the login role, say "my_application"

I also expect "public" to remain on the search path for each executed migration.

What did you see instead?

Metadata table and application's schema objects are in "public" schema.

Ideas (mutually exclusive):

  • do select current_schema instead of parsing search_path
  • if you're going to modify search_path, backup and restore the entire search_path expression I stand corrected
  • document that migrations don't get to make a change to search_path that's visible to subsequent migrations. There are at least a dozen other bad ideas like this where flyway currently doesn't try to compensate :)
  • document that migration authors are responsible for establishing any preconditions their migrations might have besides being connected to the correct database
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Feb 15, 2018

Thanks for the report. Related to #1407

Note that we do actually back up and restore the full search_path.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Feb 17, 2018

@daniel-huss Could you elaborate a little on the following:

document that migrations don't get to make a change to search_path that's visible to subsequent migrations. There are at least a dozen other bad ideas like this where flyway currently doesn't try to compensate :)

We of course do this so that a migration run with V1 and V2 would result in the same database as two separate migration runs where the first would only do V1 and the second only V2. What other bad ideas do you feel we should compensate for and currently aren't?

document that migration authors are responsible for establishing any preconditions their migrations might have besides being connected to the correct database

Which preconditions exactly do you have in mind?

@ghost ghost changed the title postgres: flyway uses "public" schema instead of current_schema and messes with search_path postgres: flyway uses "public" schema instead of current_schema and changes search_path Feb 22, 2018
@ghost
Copy link
Author

@ghost ghost commented Feb 22, 2018

Thank you for giving me a chance to explain this more clearly, I'm genuinely bad at communicating with people.

What I was really trying to say is: I strongly believe Flyway should never ever touch the session state, nor should migrations, nor should other application code. Session state should be considered all set up and read-only once the application obtains some JDBC Connection instance from a DataSource.

I actually don't want Flyway to compensate for any problems caused by altered session state, current_schema just being a subset of that state.

If I'm not mistaken, Flyway setting current_schema was introduced for #1108. I disagree with its author about the part where Flyway should be responsible for reversing a session state change it didn't make.

If some migration really needs to temporarily alter session state because there's no equivalent to Postgres' set local, it should do so in a try...finally block.

Those documentation "ideas" otoh are probably just me trying to make the other option (=Flyway taking responsibility for session state) look bad. Sorry about that.

@axelfontaine axelfontaine changed the title postgres: flyway uses "public" schema instead of current_schema and changes search_path PostgreSQL: Flyway uses "public" schema instead of current_schema when search_path starts with $user Feb 26, 2018
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Feb 26, 2018
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Feb 26, 2018

I ended up going for the select current_schema route, completely eliminating the search path parsing logic

dohrayme pushed a commit to dohrayme/flyway that referenced this issue Feb 3, 2020
…urrent_schema when search_path starts with $user
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.