-- 一个租户允许多个商户编号（2026-09-24 用户裁定）
-- 手工执行: psycopg2 / psql 连接 payment_platform_java 库
--
-- 【本脚本尚未执行】执行由用户做。
--
-- ── 背景 ─────────────────────────────────────────────────────────────
-- db/har-tenant-level.sql 在 2026-09-24 早些时候建了这条索引：
--     uk_har_merchant_tenant_level  ON pay_har_merchant (tenant_id)
--                                   WHERE enterprise_id IS NULL
-- 它的语义是「一个租户只能有一条租户级商户映射」。用户随后裁定：
-- **一个租户允许配置多个商户** ⇒ 这条索引必须去掉，否则第二条永远插不进去
-- （报 23505 唯一约束冲突，落到 GlobalExceptionHandler 就是一句 500）。
--
-- 去掉了会不会失去保护？不会：
--   · merchant_code 仍是**全局**唯一（uk_har_merchant_code，V1.8 建表时就有）
--     ⇒ 同一个商户编号不可能被插两次，跨租户也不行；
--   · enterprise_id 仍是**全局**唯一（uk_har_merchant_enterprise）
--     ⇒ 一个企业不会挂到两条映射上。
-- 也就是说本条索引本来只管「租户内条数」，而条数现在由业务自己决定。
--
-- ⚠ 代价（如实写）：多条之后，「用哪一条」不再有唯一答案。
--   代码侧已按「谁下单谁指定」处理 —— HarMerchantService#requireByTenant 在该租户有
--   多条时抛 400「请指定 merchant_code」，**不做 LIMIT 1 随便挑**（挑错了钱会进错
--   商户账号，且全程无报错）。请求体里新增的 merchant_code 见三个入参：
--   HarOrderCreateDTO / HarShopCreateDTO / HarOpenOrderQueryDTO（查单也要带 ——
--   不带而本租户有多条时，那句 400 提示就成了无法照办的死路）。
--
-- 顺序：本脚本与代码**同批**上即可，不像 har-tenant-level.sql 那样有先后约束 ——
-- 代码在索引还在时也能跑（只是第二个商户存不进去），索引先删也不会让老代码出错。

DROP INDEX IF EXISTS uk_har_merchant_tenant_level;


-- ── 只读核对（执行后手工跑一遍）──────────────────────────────────────
--
-- 1) 那条索引确实没了（**期望 0 行**）
--   SELECT indexname FROM pg_indexes
--    WHERE indexname = 'uk_har_merchant_tenant_level';
--
-- 2) 两道仍然在的保护（**期望 2 行**）
--   SELECT indexname FROM pg_indexes
--    WHERE indexname IN ('uk_har_merchant_enterprise', 'uk_har_merchant_code');
--   ★ 若这两行少了一行，先别建第二条商户 —— 那是重复商户编号的唯一防线。
--
-- 3) 端到端（唯一能证明「多个商户」真的成立的一条）：
--   用超管在「商户配置」页给**同一个租户**录两条 merchant_code（第二条留空企业），
--   两条都应保存成功；再用该租户的账号调开放 API 下单：
--     · 不带 merchant_code ⇒ 400「当前租户配置了多个商户编号，请在请求中指定 merchant_code」；
--     · 带其中一条 ⇒ 成功，且订单列表里那一行的商户编号就是它。