Flyway: Default placeholder is not populated

[feoktant]

Which version and edition of Flyway are you using?

6.2.3, 6.2.4

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

Java API

Which database are you using (type & version)?

Postgres 11.6

Which operating system are you using?

Ubuntu

What did you do?

Little repo to reproduce my issue.
I try to get default placeholders in my migration scripts as it is described here.
Here is sample java main:

    public static void main(String[] args) {
        String schemaName = "test_schema";
        Flyway.configure()
            .dataSource(
                "jdbc:postgresql://localhost:5432/postgres",
                "postgres",
                "mysecretpassword")
            .locations("db/migrations")
            .defaultSchema(schemaName)
            .schemas(schemaName)
            .load()
            .migrate();
    }

And my scripts:

create table A(schema_name varchar);
insert into A values('${flyway:defaultSchema}');

What did you expect to see?

Placeholder was substituted by value test_schema.
test_schema string inserted into table A.

What did you see instead?

INFO: Current version of schema "test_schema": << Empty Schema >>
Exception in thread "main" org.flywaydb.core.api.FlywayException: Unable to parse statement in db/migrations/V1__create_table.sql at line 1 col 37: Failed to populate value for default placeholder: ${flyway:defaultSchema}

[bhavanki]

I am seeing this same problem under Flyway 6.1.0.

It seems that the placeholder doesn't get filled in if the schema doesn't yet exist. I find that PostgreSQL (9.6.15) returns an empty string for SELECT current_schema if the schema does not yet exist, even if it is the sole member of search_path. (Flyway executes this select in PostgreSQLConnection::doGetCurrentSchema.)

My Java application fails to start the first time I run it, but before it fails, Flyway creates the schema and does some migrations, before hitting one needing flyway:defaultSchema. If I run the application again, it stays up, because the schema exists now.

[juliahayward]

What I'm seeing is that PostgreSQLConnection::doGetCurrentSchema() returns public rather than test_schema, so in the above example table A is populated but not with what I'd expect. I'm thinking that this placeholder value would be more correctly substituted by the defaultSchema config parameter rather than the current schema, which as we've seen may not exist or may be the wrong one. What do you think?

[Lyeeedar]

Fixed in c2297307f4bc056ea29a5e4d32f7eab8f39c81a4