-- 20260402030000_strict_employee_separation's own comment documents this:
-- the migration originally did `DROP TABLE employees CASCADE` to replace
-- the old users-linked employees (created by
-- 20260317190000_complete_users_schema) with the new standalone-auth
-- shape. That DROP was later removed from the file because the old
-- db-migrate tool replayed every .sql on every run, turning a one-time
-- transformation into one that wiped live employee accounts on every
-- deploy. Production made this transition long ago, so the file was
-- simplified to a plain `CREATE TABLE IF NOT EXISTS`.
--
-- But on any environment that hasn't made that transition yet -- a fresh
-- bootstrap chief among them -- 20260317190000's old-shape `employees`
-- (user_id/role_id, no email/password_hash) is still sitting there, so
-- 20260402030000's CREATE TABLE IF NOT EXISTS no-ops against it and the
-- very next statement (CREATE INDEX ... employees(email)) fails.
--
-- This restores the original one-time DROP, but gated: it only fires if
-- employees still has the old pre-transition shape (no `email` column).
-- Any environment that already transitioned (all real ones today, per the
-- comment above) is untouched.
DO $$
BEGIN
    IF EXISTS (SELECT 1 FROM information_schema.tables WHERE table_name = 'employees')
       AND NOT EXISTS (
           SELECT 1 FROM information_schema.columns
           WHERE table_name = 'employees' AND column_name = 'email'
       ) THEN
        DROP TABLE employees CASCADE;
    END IF;
END $$;
