-- Idempotency key for uploads, supplied by the client.
--
-- The failure this closes is the ordinary one on a phone, not an exotic race: the server
-- receives the body, validates it, commits the row, and the response is lost on the way back
-- because the guest walked out of range or the AP dropped the connection. The client sees a
-- network error with the blob still in hand, marks the item retryable, and re-sends it — both
-- when the guest taps "Erneut" and automatically when the queue requeues on reconnect. Every
-- attempt minted a fresh `Uuid::new_v4()` server-side, so the same photo landed in the gallery
-- two or three times and was charged against the guest's storage quota each time.
--
-- The client already has a stable per-queue-item UUID, so it costs nothing to send. NULL is
-- allowed and unconstrained: uploads that predate this column, and any client that doesn't send
-- one, keep working exactly as before.
ALTER TABLE upload ADD COLUMN client_upload_id UUID;

-- Partial rather than a plain UNIQUE. Postgres would tolerate the NULLs either way, but indexing
-- only the rows that carry a key keeps it small and states the rule exactly: uniqueness applies
-- where a key exists, and nowhere else.
--
-- Scoped globally rather than per user or per event. The key is a client-generated v4 UUID, so a
-- collision between two different photos is not a real possibility, and a single-column index
-- means the uniqueness check cannot be wrong about which event or user a retry belongs to.
CREATE UNIQUE INDEX upload_client_upload_id_key
    ON upload (client_upload_id)
    WHERE client_upload_id IS NOT NULL;