Clean tries to drop a function from an extension and fails #100

flyway · 2013-06-25T09:58:30Z

Original author: Martin.A...@gmail.com (May 11, 2012 10:11:31)

We are using PostgreSQL 9.1 and are using the uuid-ossp extension. Clean tries to drop one of its functions. The extension has been installed manually as it required adding binaries to the DBMS.

Any way to work around this?

FlywayException: Error executing statement at line 64: DROP FUNCTION IF EXISTS "public"."uuid_nil"() CASCADE
Occured in com.googlecode.flyway.core.migration.sql.SqlStatement in method execute, line number 78
Caused by org.postgresql.util.PSQLException: ERROR: cannot drop function uuid_nil() because extension uuid-ossp requires it
Hint: You can drop extension uuid-ossp instead.
Occured in org.postgresql.core.v3.QueryExecutorImpl in method receiveErrorResponse, line number 2102

Original issue: http://code.google.com/p/flyway/issues/detail?id=257

flyway · 2013-06-25T09:58:31Z

From axel.fontaine.business@gmail.com on May 22, 2012 00:08:11
Hi Martin,

thanks for your report. Sorry for the late reply. I've thought about this a bit.

Do you believe the following solution would work?

Add support to Flyway to clean extension (using DROP EXTENSION)
Add a CREATE EXTENSION line to your initial migration

Looking forward to your feedback
Axel

P.S.: There are 2 things that still would need to be researched: how to do this with 9.0 and how to enumerate the installed extensions.

flyway · 2013-06-25T09:58:32Z

From Martin.A...@gmail.com on May 22, 2012 20:15:00
Looks like a feasible solution. Let me explain what actions we took when establishing our migration using the extension.
1.) The uuid-ossp extension requires a binary/os-specific addon. On the windows platform that was already installed. For linux we had to get the package first and install it
2.) Since the extension required some additional software to be installed we decided not to have the CREATE EXTENSION statement as part of the migration script

Still the cleanup tries to delete individual functions from the extension. So either during cleanup functions from extensions are left alone or only a drop extension command is executed.

flyway · 2013-06-25T09:58:32Z

From Martin.A...@gmail.com on May 29, 2012 20:15:21
As we are currently looking for a workaround for the failing clean process, we have a question regarding the reason why clean is actually performing a 'object by object' delete process?
How much would it differ from a simple DROP SCHEMA, CREATE SCHEMA sequence?

flyway · 2013-06-25T09:58:33Z

From axel.fontaine.business@gmail.com on June 04, 2012 19:12:18
Hi Martin,

I've added the answer to your question to the FAQ: http://code.google.com/p/flyway/wiki/FAQ?ts=1338836686&updated=FAQ#Why_does_clean_drop_individual_data_objects_instead_of_the_schem

I have been pondering the question of leaving functions from extensions alone vs drop extension. I am still undecided. I currently lean towards the latter as the former would invalidate the promise to truly clean the schema of all its objects. The disadvantage of this is of course the required introduction of separate cleaning methods for 9.0 and 9.1.

Input and/or contributions welcome.

Cheers
Axel

flyway · 2013-06-25T09:58:33Z

From kevin...@gmail.com on February 11, 2013 16:44:49
Doing DROP/CREATE SCHEMA may be useful for some situations, but there are many extensions which require superuser privileges to install/remove (e.g. isn), and others which do not require superuser may still be managed by a database administrator team which would prevent application developers (or the application user) from modifying them.

A local modification that I am using is to only drop objects when running as superuser or when the object is owned by the user (since the drop would fail otherwise and the object is not likely to be part of the migration).

The solution is not perfect. It may surprise users if some objects are left installed. This could, perhaps, be more transparent if a warning was issued or if it required a configuration option (dropObjects/dropOwnObjects/dropAllObjects or similar).

flyway · 2013-06-25T09:58:34Z

From kevin...@gmail.com on February 11, 2013 16:45:40
Sorry, in my last comment I meant DROP/CREATE EXTENSION rather than DROP/CREATE SCHEMA.

flyway · 2013-06-25T09:58:37Z

From laser.ta...@googlemail.com on March 08, 2013 21:59:35
Hi there, is there any solution yet?

I have the same problem with the extension postgis, which creates a table.
So when running clean the table cannot be dropped because postgis extension is still enabled...

flyway · 2013-06-25T09:58:38Z

From axel.fontaine.business@gmail.com on March 12, 2013 09:57:28
No solution yet.

Somehow I feel that the best solution/workaround involves putting your objects in your own schema, so extensions don't interfere and Flyway doesn't have to deal with them.

Comments/contributions/pull requests welcome.

wilkko · 2013-10-23T06:50:54Z

+1 for cleaning the schema of all its objects

bjhartin · 2013-11-12T16:49:32Z

I have submitted pull request #629, which would allow us to extend any of the DbSupport classes. This makes it trivial to override doClean(), as demonstrated by the 'CustomCleanTest' in the core module.

sfitts · 2014-07-21T17:59:21Z

Just ran into this when adding Postgres support. Surprised that there is still no solution.

cowwoc · 2014-09-16T21:06:43Z

@axelfontaine I think @bjhartin might have dropped out and I agree with @sfitts that this issue is very annoying while doing Postgres development.

Any chance you could take another look at it?

svmehta · 2014-10-03T00:15:00Z

+1

cowwoc · 2014-10-07T17:09:22Z

@axelfontaine

I used callbacks to work around this issue (thank you!)

Just a head's up... Even once you fix this problem (dropping extensions), you'll also need to ensure you drop views before attempting to drop "basic types". Otherwise you'll get another error.

For those of you wanting to implement your own workaround, please see #629 (comment)

marcomorain · 2014-11-15T20:58:37Z

👍

rdifalco · 2014-12-01T20:20:07Z

I am having this problem. I have a migration that adds an extension for pg_trgm. Then I'm dead in the water for unit testing when I call flyway.clean(). What is the current workaround for this?

axelfontaine · 2014-12-01T20:21:31Z

Put your own objects in a different schema than public
Am 01.12.2014 21:20 schrieb "Robert DiFalco" notifications@github.com:

I am having this problem. I have a migration that adds an extension for
pg_trgm. Then I'm dead in the water for unit testing when I call
flyway.clean(). What is the current workaround for this?

—
Reply to this email directly or view it on GitHub
#100 (comment).

rdifalco · 2014-12-01T20:22:53Z

Sorry Axel, I don't know what that means. Do you mean take "CREATE EXTENSION pg_trgm" out of my flyway migration file and do it manually?

cowwoc · 2014-12-01T20:35:54Z

@rdifalco See #100 (comment) for a workaround. You register a FlywayCallback with Flyway, then implement beforeClean() to drop the function before Flyway tries to drop it itself.

marcomorain · 2014-12-01T21:07:16Z

Is there a way to implement a callback with an SQL file rather than in Java?

cowwoc · 2014-12-01T21:11:23Z

@marcomorain This is only possible in Flyway 3.1. See #728

marcomorain · 2014-12-01T21:23:18Z

I'll give that a try when I get a change. Thanks.

On Mon, Dec 1, 2014 at 1:11 PM, cowwoc notifications@github.com wrote:

@marcomorain https://github.com/marcomorain This is only possible in
Flyway 3.1. See #728 #728

—
Reply to this email directly or view it on GitHub
#100 (comment).

axelfontaine · 2014-12-03T08:19:58Z

Let's revisit this for 3.2

This could be a starting point: http://stackoverflow.com/questions/25387168/how-to-find-all-user-defined-not-extension-related-functions-in-postgresql

Pull request or sponsoring welcome.

imjoshholloway · 2015-04-16T10:44:23Z

Just incase someone comes looking here and doesn't fancy jumping between the issues to figure out a work around:

Create a beforeClean.sql file in your migrations folder and add the required DROP... command into it.

For example, if like me, when doing flyway clean -X you get: ERROR: cannot drop function uuid_nil() because extension uuid-ossp requires it you would add the following into the beforeClean.sql file:

DROP EXTENSION IF EXISTS "uuid-ossp" CASCADE;

smrnv · 2017-02-08T21:42:56Z

+1

b0dh1 · 2017-02-09T08:55:27Z

+1

matsandreassen · 2017-08-24T16:43:33Z

+1

Just attempted to use Flyway with a PostGIS-enabled database in an integration test. Cleaning fails with:

org.flywaydb.core.internal.dbsupport.FlywaySqlException:
Unable to drop "public"."spatial_ref_sys"

SQL State : 2BP01
Error Code : 0
Message : ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
Hint: You can drop extension postgis instead.

ttaranov · 2017-09-17T13:33:46Z

+1, same as above - clean doesn't work with Postgres databases with PostGIS extension installed.

matsandreassen · 2017-09-17T18:08:15Z

The reason we're encountering this is because we put our tables inside "public". There's a workaround to this which I've "uncovered" on Stackoverflow and the like. I'll try to re-iterate the solution:

Create new schema. E.g. "myschema"
To enable PostGIS extension on "myschema", execute:
ALTER DATABASE <YOUR_DATABASE> SET search_path = myschema, public;
ALTER USER <YOUR_USER> SET search_path = myschema, public;
Ensure all your migrations create tables in "myschema".
Finally, and I'm not sure why right now, Flyway does not seem to honor the schema setting in your jdbc-url. E.g. jdbc:postgresql://locahost:5432/mydb?currentSchema=myschema
I came over this script (pretty sure it was on Stackoverflow):

Put in 'beforeEachMigrate.sql' on your migration path:

DO $$
DECLARE
default_search_path TEXT := NULL;
BEGIN
SELECT setting_value INTO default_search_path
FROM (
SELECT
substring(setting from 1 for eq_position - 1) AS setting_name,
substring(setting from eq_position + 1) AS setting_value
FROM (
SELECT position('=' in setting) AS eq_position, setting
FROM (
SELECT UNNEST(setconfig) AS setting FROM pg_db_role_setting s JOIN pg_database d ON s.setdatabase = d.oid WHERE d.datname = current_database()
) raw_db_role_settings
) presplit_db_role_settings
) split_db_role_settings
WHERE setting_name = 'search_path';

IF default_search_path IS NOT NULL THEN
EXECUTE 'SET search_path = '||default_search_path;
END IF;
END;
$$

Took me a while to figure this out but this solution seems to have no side effects. :)

foal · 2017-10-19T18:05:40Z

I had the same issue with hstore extension (required superuser). Just create it in PG_CATALOG schema while setup test database as superuser.

CREATE EXTENSION hstore SCHEMA pg_catalog

In that case no need to set up search_paht.

axelfontaine · 2018-02-18T17:57:02Z

This is now working as expected. As long as you create your extensions with CREATE EXTENSION IF NOT EXISTS you should now be able to clean your schema and rebuild it just fine.

maraswrona · 2018-03-26T14:14:39Z

@axelfontaine unfortunately this is still not working for me. My setup:

flyway version: tried both 5.0.7 (recent) and 3.2.1 (embedded in spring boot)

V1__init.sql:

CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE mytable (
    id SERIAL PRIMARY KEY,    
    location geometry NOT NULL    
);

Then running against clean db:

$ ./flyway migrate
Flyway Community Edition 5.0.7 by Boxfuse

Database: jdbc:postgresql://localhost:5432/airlydb (PostgreSQL 9.5)
Successfully validated 1 migration (execution time 00:00.009s)
Creating Schema History table: "public"."flyway_schema_history"
Current version of schema "public": << Empty Schema >>
Migrating schema "public" to version 1 - init
Successfully applied 1 migration to schema "public" (execution time 00:00.900s)

And then:

$ ./flyway clean -X
Flyway Community Edition 5.0.7 by Boxfuse

DEBUG: Java 1.8.0_152 (Oracle Corporation)
DEBUG: Windows 10 10.0 amd64

DEBUG: Loading config file: C:\dev\apps\flyway-5.0.7\conf\flyway.conf
DEBUG: Unable to load config file: C:\Users\m.woroniecki\flyway.conf
DEBUG: Unable to load config file: C:\dev\apps\flyway-5.0.7\flyway.conf
DEBUG: Using configuration:
DEBUG: flyway.jarDirs -> C:\dev\apps\flyway-5.0.7\jars
DEBUG: flyway.password -> *****
DEBUG: flyway.url -> jdbc:postgresql://localhost:5432/airlydb
DEBUG: flyway.user -> postgres
DEBUG: flyway.locations -> filesystem:C:\dev\apps\flyway-5.0.7\sql
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\derby-10.12.1.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\derbyclient-10.12.1.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\h2-1.4.196.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\hsqldb-2.4.0.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\jtds-1.3.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\mariadb-java-client-2.2.0.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\mssql-jdbc-6.2.2.jre7.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\postgresql-42.1.4.jre6.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\sqlite-jdbc-3.20.1.jar
Database: jdbc:postgresql://localhost:5432/airlydb (PostgreSQL 9.5)
DEBUG: DDL Transactions Supported: true
DEBUG: Schema: public
DEBUG: Spring Jdbc available: false
DEBUG: Scanning for SQL callbacks ...
DEBUG: Scanning for filesystem resources at 'C:/dev/apps/flyway-5.0.7/sql' (Prefix: '', Suffixes: '.sql')
DEBUG: Scanning for resources in path: C:\dev\apps\flyway-5.0.7\sql (C:/dev/apps/flyway-5.0.7/sql)
DEBUG: Filtering out resource: C:\dev\apps\flyway-5.0.7\sql\put-your-sql-migrations-here.txt (filename: put-your-sql-migrations-here.txt)
DEBUG: Found filesystem resource: C:\dev\apps\flyway-5.0.7\sql\V1__init.sql
DEBUG: Cleaning schema "public" ...
DEBUG: Rolling back transaction...
DEBUG: Transaction rolled back
ERROR: Unexpected error
org.flywaydb.core.internal.exception.FlywaySqlException:
Unable to drop "public"."spatial_ref_sys"
-----------------------------------------
SQL State  : 2BP01
Error Code : 0
Message    : ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
  Wskaz▒wka: You can drop extension postgis instead.

        at org.flywaydb.core.internal.database.SchemaObject.drop(SchemaObject.java:83)
        at org.flywaydb.core.internal.database.postgresql.PostgreSQLSchema.doClean(PostgreSQLSchema.java:86)
        at org.flywaydb.core.internal.database.Schema.clean(Schema.java:149)
        at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:179)
        at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:176)
        at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
        at org.flywaydb.core.internal.command.DbClean.cleanSchema(DbClean.java:176)
        at org.flywaydb.core.internal.command.DbClean.clean(DbClean.java:124)
        at org.flywaydb.core.Flyway$3.execute(Flyway.java:1306)
        at org.flywaydb.core.Flyway$3.execute(Flyway.java:1299)
        at org.flywaydb.core.Flyway.execute(Flyway.java:1655)
        at org.flywaydb.core.Flyway.clean(Flyway.java:1299)
        at org.flywaydb.commandline.Main.executeOperation(Main.java:157)
        at org.flywaydb.commandline.Main.main(Main.java:108)
Caused by: org.postgresql.util.PSQLException: ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
  Wskaz▒wka: You can drop extension postgis instead.
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
        at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:158)
        at org.flywaydb.core.internal.util.jdbc.JdbcTemplate.execute(JdbcTemplate.java:246)
        at org.flywaydb.core.internal.database.postgresql.PostgreSQLTable.doDrop(PostgreSQLTable.java:43)
        at org.flywaydb.core.internal.database.SchemaObject.drop(SchemaObject.java:81)
        ... 13 more

You said

This is now working as expected. As long as you create your extensions with CREATE EXTENSION IF NOT EXISTS you should now be able to clean your schema and rebuild it just fine.

Could you provide a working example please?

axelfontaine · 2018-03-26T14:39:04Z

@maraswrona Check the milestone set for this issue. The fix is in the latest sources.

maraswrona · 2018-03-26T14:43:15Z

ah.... so I guess the fix will be in the next release? Thanks for the clarification.

hgl · 2018-04-16T07:31:57Z

Does the fix work with users without superuser privilege?

Sorry if I could just build from source myself and find out, but I'm not familiar with java, have no idea how to build 5.1.0 from github source.

ghost · 2018-05-11T17:47:36Z

This is not working for me either.

I am using

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>
<dependency>
    <groupId>org.flywaydb.flyway-test-extensions</groupId>
    <artifactId>flyway-spring-test</artifactId>
    <version>5.0.0</version>
    <scope>test</scope>
</dependency>

or

[INFO] +- org.flywaydb:flyway-core:jar:5.0.7:compile
[INFO] +- org.flywaydb.flyway-test-extensions:flyway-spring-test:jar:5.0.0:test

in a Spring Boot (2.0.1.RELEASE) application. However, running my unit tests will throw:

org.flywaydb.core.internal.exception.FlywaySqlException: 
Unable to clean schema "public"
-------------------------------
SQL State  : 2BP01
Error Code : 0
Message    : ERROR: cannot drop type cube because extension cube requires it
  Hint: You can drop extension cube instead.


	at org.flywaydb.core.internal.database.Schema.clean(Schema.java:151)
	at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:179)
	at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:176)
	at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
	at org.flywaydb.core.internal.command.DbClean.cleanSchema(DbClean.java:176)
	at org.flywaydb.core.internal.command.DbClean.clean(DbClean.java:124)
	at org.flywaydb.core.Flyway$3.execute(Flyway.java:1306)
	at org.flywaydb.core.Flyway$3.execute(Flyway.java:1299)
	at org.flywaydb.core.Flyway.execute(Flyway.java:1655)
	at org.flywaydb.core.Flyway.clean(Flyway.java:1299)
	at org.flywaydb.test.FlywayTestExecutionListener.dbResetWithAnnotation(FlywayTestExecutionListener.java:378)
	at org.flywaydb.test.FlywayTestExecutionListener.handleFlywayTestAnnotationForClass(FlywayTestExecutionListener.java:178)
	at org.flywaydb.test.FlywayTestExecutionListener.beforeTestClass(FlywayTestExecutionListener.java:157)
	at org.springframework.test.context.TestContextManager.beforeTestClass(TestContextManager.java:215)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:60)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: org.postgresql.util.PSQLException: ERROR: cannot drop type cube because extension cube requires it
  Hint: You can drop extension cube instead.
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
	at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:158)
	at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
	at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
	at org.flywaydb.core.internal.util.jdbc.JdbcTemplate.execute(JdbcTemplate.java:246)
	at org.flywaydb.core.internal.database.postgresql.PostgreSQLSchema.doClean(PostgreSQLSchema.java:90)
	at org.flywaydb.core.internal.database.Schema.clean(Schema.java:149)
	... 22 more

ghost · 2018-05-11T17:49:13Z

@axelfontaine Oh I only just saw your comment: Is it not supposed to work with 5.0.7?

ghost · 2018-05-11T18:04:40Z

Okay, I'll repeat what @foal said because it's easily overlooked.

If you can, just install your extensions with pg_catalog. In my case I put

CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA pg_catalog;
CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA pg_catalog;

in my V1__init.sql script.

Now my tests are running without problems.

zarinfam · 2018-06-26T08:36:23Z

I had this problem for test environment, see this answer https://stackoverflow.com/questions/46656531#51038385

svpace · 2018-12-02T17:18:13Z

@axelfontaine perhaps I'm doing something wrong here but with flyway-core-5.2.1 and "create extension if not exists" on public (not pg_catalog) and I'm still getting the "ERROR: cannot drop table spatial_ref_sys because extension postgis ..." error on clean.

axelfontaine · 2018-12-03T08:14:30Z

@svpace Please open a new issue with exact steps how to reproduce.

axelfontaine mentioned this issue Dec 3, 2014

Clean throws exception with Postgres with Extension #899

Closed

axelfontaine added this to the Flyway 3.2 milestone Dec 3, 2014

axelfontaine mentioned this issue Jan 28, 2015

Postgresql, clear extensions #942

Closed

axelfontaine added the s: sponsoring welcome label Jan 28, 2015

axelfontaine modified the milestones: Flyway 4.0, Flyway 3.2 Mar 5, 2015

axelfontaine modified the milestones: Flyway 5.0, Flyway 4.1 Feb 1, 2017

axelfontaine removed the s: sponsoring welcome label Nov 26, 2017

axelfontaine modified the milestones: Flyway 5.0.0, Flyway 5.1.0 Nov 26, 2017

sabahirfan mentioned this issue Jan 12, 2018

ROC-2926: Combine title and name fields for individual hmcts/cmc-claim-store#141

Merged

axelfontaine mentioned this issue Jan 26, 2018

Initial Schema reported as not empty (view pg_stat_statements exists) #1908

Closed

axelfontaine mentioned this issue Feb 17, 2018

Do not delete types that extensions depend on when cleaning PostgreSql #1932

Merged

axelfontaine closed this as completed Feb 18, 2018

axelfontaine added the r: fixed label Feb 18, 2018

ghost mentioned this issue May 11, 2018

ERROR: cannot drop type <type> because extension <extension> requires it flyway/flyway-test-extensions#56

Closed

CatalinaMoisuc mentioned this issue Jun 25, 2018

PostgreSQL: clean fails when trying to drop aggregates added by extensions #2051

Closed

flyway locked as resolved and limited conversation to collaborators Dec 3, 2018

Clean tries to drop a function from an extension and fails #100

Clean tries to drop a function from an extension and fails #100

Comments

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

flyway commented Jun 25, 2013

wilkko commented Oct 23, 2013

bjhartin commented Nov 12, 2013

sfitts commented Jul 21, 2014

cowwoc commented Sep 16, 2014

svmehta commented Oct 3, 2014

cowwoc commented Oct 7, 2014

marcomorain commented Nov 15, 2014

rdifalco commented Dec 1, 2014

axelfontaine commented Dec 1, 2014

rdifalco commented Dec 1, 2014

cowwoc commented Dec 1, 2014

marcomorain commented Dec 1, 2014

cowwoc commented Dec 1, 2014

marcomorain commented Dec 1, 2014

axelfontaine commented Dec 3, 2014

imjoshholloway commented Apr 16, 2015

smrnv commented Feb 8, 2017

b0dh1 commented Feb 9, 2017

matsandreassen commented Aug 24, 2017

org.flywaydb.core.internal.dbsupport.FlywaySqlException: Unable to drop "public"."spatial_ref_sys"

ttaranov commented Sep 17, 2017

matsandreassen commented Sep 17, 2017

foal commented Oct 19, 2017 • edited

axelfontaine commented Feb 18, 2018

maraswrona commented Mar 26, 2018

axelfontaine commented Mar 26, 2018

maraswrona commented Mar 26, 2018

hgl commented Apr 16, 2018

ghost commented May 11, 2018

ghost commented May 11, 2018

ghost commented May 11, 2018 • edited by ghost

zarinfam commented Jun 26, 2018

svpace commented Dec 2, 2018

axelfontaine commented Dec 3, 2018

org.flywaydb.core.internal.dbsupport.FlywaySqlException:
Unable to drop "public"."spatial_ref_sys"

foal commented Oct 19, 2017 •

edited

ghost commented May 11, 2018 •

edited by ghost