-- Migration : activation RLS sur photobooth.events / photobooth.photos
-- Réf. : docs/modele-donnees.md (section "Row Level Security (RLS)")
--
-- ⚠️ Ne pas appliquer depuis cet agent (Kévin applique lui-même).

alter table photobooth.events enable row level security;
alter table photobooth.photos enable row level security;

-- Choix DÉLIBÉRÉ : AUCUNE policy sur photobooth.events ni photobooth.photos,
-- pour anon/authenticated/service_role — ni SELECT, ni INSERT, ni UPDATE, ni
-- DELETE. RLS activé + zéro policy = accès refusé par défaut pour tout rôle
-- non-BYPASSRLS.
--
-- Pourquoi (documenté suite à la consigne "garde la policy d'INSERT anon si
-- tu juges ça utile, sinon documente pourquoi tu la retires") : dans cette
-- architecture, le schéma `photobooth` n'est de toute façon JAMAIS exposé
-- via PostgREST (cf. 20260916090000_create_photobooth_schema.sql) — aucune
-- route REST n'existe pour `photobooth.photos`, donc une policy anon INSERT
-- ne servirait à rien en temps normal (personne ne peut l'atteindre par ce
-- chemin). Le SEUL chemin d'écriture pour anon est désormais la fonction
-- SECURITY DEFINER public.insert_public_photo(), qui revalide elle-même
-- event_accepts_uploads() et la cohérence url_storage/event_id avant
-- d'insérer (cf. 20260916090400_create_public_functions.sql) — et une
-- fonction SECURITY DEFINER s'exécute avec les privilèges de son
-- propriétaire, PAS ceux de l'appelant : elle n'a donc pas besoin d'une
-- policy RLS permissive pour anon afin de fonctionner.
--
-- Garder RLS activé SANS policy sert uniquement de filet de sécurité en cas
-- d'erreur humaine future (ex. quelqu'un ajoute `photobooth` aux "Exposed
-- schemas" par erreur un jour) : dans ce scénario, sans policy, un accès
-- REST direct resterait refusé pour anon/authenticated. Ajouter UNE policy
-- anon INSERT "juste au cas où" recréerait exactement le chemin
-- d'écriture non revalidé qu'on vient de fermer avec
-- public.insert_public_photo() — jugé contre-productif, donc pas ajoutée.