-- =============================================================================
-- MIGRATION: Fix slug uniqueness scope for Category, Product, Store
--
-- The initial migration (000001_init) added BOTH a global unique index on
-- `slug` AND the correct per-tenant compound unique index
-- (storeId+slug / organizationId+slug) for these three tables. The global
-- index wins at the DB layer, so two different stores (or two different
-- merchants entirely) could never both use a category/product/store slug
-- like "clothes" — even though the app-level uniqueness checks
-- (existsBySlug() etc.) were already correctly scoped per-tenant and would
-- happily let it through, right up until the raw DB constraint rejected it.
--
-- This drops only the redundant GLOBAL indexes. The compound ones
-- (categories_storeId_slug_key, products_storeId_slug_key,
-- stores_organizationId_slug_key) already exist and are correct — left
-- untouched, so slugs remain unique *within* a store/org, just not across
-- unrelated tenants.
--
-- Organization.slug and Theme.slug are deliberately NOT touched here —
-- Organization is the top-level tenant (nothing to scope it under) and
-- Theme is a genuinely shared, platform-wide catalog — both are correctly
-- globally unique already.
--
-- Run: idempotent — safe to re-execute
-- =============================================================================

BEGIN;

DROP INDEX IF EXISTS master.categories_slug_key;
DROP INDEX IF EXISTS products.products_slug_key;
DROP INDEX IF EXISTS store.stores_slug_key;

COMMIT;

-- Verify — should return zero rows (only the compound indexes remain)
SELECT indexname FROM pg_indexes
WHERE indexname IN ('categories_slug_key', 'products_slug_key', 'stores_slug_key');