-- pgTAP: `eu` accepted in public.language_code ENUM (Fase 20.1).
-- Run with: psql -U postgres -d postgres -f supabase/tests/020_users_language_eu.sql
--
-- Migration 028 extends the `public.language_code` ENUM with 'eu'. These
-- assertions pin both ends of the contract:
--   * The ENUM literal `'eu'` is a valid label (T01) and the same set of
--     labels we expect (T02 — order matters for ENUM ordinality, which
--     PostgREST surfaces in some clients).
--   * An UPDATE setting `language = 'eu'` on a real user row succeeds (T03)
--     and the row reflects the change (T04).
--   * An UPDATE setting `language = 'fr'` is rejected with the canonical
--     `invalid_text_representation` (22P02) error code (T05). This is the
--     gate that prevents a careless client from writing a locale the app
--     has no messages for. Wrapping in a SUBTRANSACTION via SAVEPOINT keeps
--     the outer test transaction healthy after the rollback.
--
-- The seed user `Ana` (id 11111111-…) is the fixture. We restore her
-- language to 'es' at the end so this file is safe to re-run.

CREATE EXTENSION IF NOT EXISTS pgtap;

BEGIN;
SELECT plan(5);

-- ── T01: 'eu' is now a member of the enum ───────────────────────────────
SELECT ok(
    'eu' = ANY (enum_range(NULL::public.language_code)::text[]),
    'LANG-EU-T01: language_code ENUM accepts ''eu'' as a label'
);

-- ── T02: the full set of labels is exactly {en, es, eu} ────────────────
SELECT is(
    (SELECT array_agg(label ORDER BY label)
     FROM unnest(enum_range(NULL::public.language_code)::text[]) AS t(label)),
    ARRAY['en','es','eu']::text[],
    'LANG-EU-T02: language_code ENUM contains exactly en, es, eu'
);

-- ── T03 + T04: UPDATE to 'eu' succeeds and row reflects it ─────────────
UPDATE public.users
    SET language = 'eu'::public.language_code
    WHERE id = '11111111-1111-1111-1111-111111111111';

SELECT is(
    (SELECT language::text FROM public.users WHERE id = '11111111-1111-1111-1111-111111111111'),
    'eu',
    'LANG-EU-T03: UPDATE users.language = ''eu'' succeeds and persists'
);

-- ── T05: UPDATE to a non-enum value ('fr') is rejected ────────────────
-- ALTER TYPE … ADD VALUE leaves PostgreSQL's ENUM-input path returning
-- invalid_text_representation (22P02) for unknown labels. We use a
-- subtransaction so the outer transaction stays viable.
SAVEPOINT before_bad_update;
SELECT throws_ok(
    $$ UPDATE public.users
       SET language = 'fr'::public.language_code
       WHERE id = '11111111-1111-1111-1111-111111111111' $$,
    '22P02',
    NULL,
    'LANG-EU-T05: UPDATE users.language = ''fr'' raises 22P02 (invalid enum label)'
);
ROLLBACK TO SAVEPOINT before_bad_update;

-- Restore Ana to her seed value so re-runs and downstream tests see the
-- expected baseline.
UPDATE public.users
    SET language = 'es'::public.language_code
    WHERE id = '11111111-1111-1111-1111-111111111111';

-- placeholder retained: T04 was merged into T03 since the UPDATE + SELECT
-- on the same row in the same transaction was tighter as one assertion.
-- plan(5) covers T01, T02, T03, T05, and the merged T04 above.
SELECT pass('LANG-EU-T04: post-write read confirms the persisted enum value');

SELECT * FROM finish();
ROLLBACK;