You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In case of Postgres migrations, for initial migrations where we setup schemas, it's common to use CREATE <table> IF NOT EXISTS. Though when creating user defined types, Postgres does not support this. The solution is to wrap type creations in try/catch and ignore duplicate exceptions, as shown below
DO $$ BEGINCREATETYPEmy_custom_typeAS ENUM(
'Hello',
'world'
);
EXCEPTION
WHEN duplicate_object THEN null;
END $$;
I saw there were issues filed for similar cases earlier as well.
ref: #495 (review) #1018
I understand the database specific implementations for parsing SQL and why golang-migrate resorted to a simple one based on ;
Describe the solution you'd like
Ability to specify a custom parser via config. e.g. the multistmt package can define an interface like, and accept any implementation.
Describe alternatives you've considered
If the migration returns an error with the specific error (by searching the error text), handle the migration explicitly from within the app, and then force a version upgrade. This seems cumbersome and prone to errors over time.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
In case of Postgres migrations, for initial migrations where we setup schemas, it's common to use
CREATE <table> IF NOT EXISTS
. Though when creating user defined types, Postgres does not support this. The solution is to wrap type creations in try/catch and ignore duplicate exceptions, as shown belowI saw there were issues filed for similar cases earlier as well.
ref:
#495 (review)
#1018
I understand the database specific implementations for parsing SQL and why golang-migrate resorted to a simple one based on
;
Describe the solution you'd like
Ability to specify a custom parser via config. e.g. the multistmt package can define an interface like, and accept any implementation.
Describe alternatives you've considered
If the migration returns an error with the specific error (by searching the error text), handle the migration explicitly from within the app, and then force a version upgrade. This seems cumbersome and prone to errors over time.
The text was updated successfully, but these errors were encountered: