The issue here is that Laravel's $table->enum(...)->change() is not fully supported on PostgreSQL. Unlike MySQL, PostgreSQL does not have a native ENUM type in Laravel migrations—Laravel emulates it using a VARCHAR column with a CHECK constraint. However, Laravel's schema builder does not handle updating the CHECK constraint when you use ->change() on an enum column. This results in the syntax error you see.
How to fix it:
You need to manually drop the old check constraint and add a new one with the updated values. Here’s how you can do it in a migration:
-
Find the name of the existing check constraint.
By default, Laravel does not name the check constraint, so PostgreSQL gives it an auto-generated name (e.g.,customers_type_check). You can find it with:SELECT conname FROM pg_constraint WHERE conrelid = 'customers'::regclass AND contype = 'c'; -
Write a raw migration to drop and recreate the constraint.
use Illuminate\Database\Migrations\Migration; use Illuminate\Support\Facades\DB; class UpdateCustomerTypeEnum extends Migration { public function up() { // Drop the old check constraint DB::statement('ALTER TABLE customers DROP CONSTRAINT IF EXISTS customers_type_check'); // Add the new check constraint with the updated enum values DB::statement("ALTER TABLE customers ADD CONSTRAINT customers_type_check CHECK (type IN ('value1', 'value2', 'new_value', ...))"); } public function down() { // Rollback: drop the new constraint and add the old one back DB::statement('ALTER TABLE customers DROP CONSTRAINT IF EXISTS customers_type_check'); DB::statement("ALTER TABLE customers ADD CONSTRAINT customers_type_check CHECK (type IN ('value1', 'value2', ...))"); } }Replace
'value1', 'value2', 'new_value', ...with your actual enum values.
Note:
- If you use a custom constraint name, adjust accordingly.
- If you want to automate the enum values, you can use
implodeon your enum class values.
Summary:
Laravel's enum(...)->change() does not work on PostgreSQL because it cannot update the CHECK constraint. You need to manually drop and recreate the constraint using raw SQL in your migration.