Introduzione al debug di PL/pgSQL

Allora, immagina di aver scritto una funzione o procedura bella complessa. Già ti vedi quanto spacca il tuo database, ma poi — boom! — i dati non sono quelli giusti, le query vanno lente, e il capo inizia a sudare freddo. Ed è qui che entra in gioco il debug.

Il debug in PL/pgSQL serve per:

• Trovare errori di logica, tipo quando una funzione restituisce qualcosa di diverso da quello che ti aspettavi.
• Capire cosa succede con dati di input strani. Perché a volte gli utenti del database inseriscono non solo dati, ma anche... roba totalmente incomprensibile!
• Risolvere problemi di performance. Perché il codice scritto di fretta può andare lento come una tartaruga che cerca il Wi-Fi nel deserto del Sahara.

Scherzi a parte, il debug non è solo trovare e correggere bug. È un modo per migliorare il tuo codice, renderlo più veloce, efficiente e leggibile.

Approcci principali al debug di PL/pgSQL

Il debug in PL/pgSQL si può fare in diversi modi. Vediamoli uno per uno.

1. Uso degli strumenti integrati di PostgreSQL

PostgreSQL offre alcune funzionalità integrate per la diagnostica, tra cui funzioni di logging (RAISE NOTICE e RAISE EXCEPTION), e anche l’analisi del piano di esecuzione delle query (EXPLAIN ANALYZE). Questi strumenti ti aiutano a capire cosa succede dentro la tua funzione.

2. Logging con RAISE NOTICE

RAISE NOTICE è il tuo migliore amico se vuoi capire quali dati passano nella funzione, in che punto qualcosa va storto, o controllare i valori delle variabili. Diversamente da RAISE EXCEPTION, non interrompe l’esecuzione della funzione. Per esempio, puoi stampare il contenuto di una variabile a ogni step.

DO $$
DECLARE
    counter INT := 0;
BEGIN
    FOR counter IN 1..5 LOOP
        RAISE NOTICE 'Valore attuale del contatore: %', counter;
    END LOOP;
END $$;

Questo codice stampa i valori di counter da 1 a 5. Semplice magia, ma utilissima per il debug!

3. Uso di strumenti di terze parti

Il debug di PL/pgSQL si può fare anche con strumenti come pgAdmin (con interfaccia GUI). Ti permette di mettere breakpoint e vedere i valori delle variabili in tempo reale. Se sei uno di quelli che amano gli aiutanti visuali, pgAdmin sarà il tuo compagno ideale.

Fasi del debug

Quando inizi a fare debug di una funzione o procedura, è importante seguire una certa sequenza. Vediamo ogni fase più da vicino:

1. Analisi dei dati di input

La prima cosa da controllare sono i dati di input. Assicurati che i dati che riceve la tua funzione non abbiano errori o valori strani. Ad esempio, puoi controllare tutti i parametri in ingresso con RAISE NOTICE:

CREATE FUNCTION check_input(x INTEGER) RETURNS VOID AS $$
BEGIN
    IF x IS NULL THEN
        RAISE EXCEPTION 'Il valore di input non deve essere NULL!';
    END IF;
    RAISE NOTICE 'Valore di input: %', x;
END;
$$ LANGUAGE plpgsql;

Questo esempio mostra come avvisare gli utenti di problemi con i dati in ingresso.

2. Controllo dell’esecuzione di ogni fase

Dividi la tua funzione in blocchi logici e aggiungi RAISE NOTICE nei punti chiave. Così puoi capire esattamente dove qualcosa va storto.

CREATE FUNCTION calculate_discount(price NUMERIC, discount NUMERIC) RETURNS NUMERIC AS $$
BEGIN
    RAISE NOTICE 'Inizio funzione: prezzo %, sconto %', price, discount;

    IF price <= 0 THEN
        RAISE EXCEPTION 'Il prezzo non può essere negativo o uguale a zero!';
    END IF;

    IF discount < 0 OR discount > 100 THEN
        RAISE EXCEPTION 'Lo sconto deve essere tra 0 e 100!';
    END IF;

    RETURN price - (price * discount / 100);
END;
$$ LANGUAGE plpgsql;

Qui, a ogni fase del debug, vengono stampati messaggi utili sullo stato del processo.

3. Ottimizzazione e risoluzione dei problemi
4. Dopo che hai trovato il bug, correggilo. Se il problema riguarda la performance, usa strumenti di analisi come EXPLAIN ANALYZE per ottimizzare le query.

Applicazione pratica delle skill di debug

Vediamo un caso reale: abbiamo una funzione che aggiunge una riga in una tabella e restituisce l’ID generato. Sembra tutto logico e semplice, ma a volte la funzione va in errore e vogliamo capire perché.

Funzione originale:

CREATE FUNCTION add_student(name TEXT, age INTEGER) RETURNS INTEGER AS $$
DECLARE
    new_id INTEGER;
BEGIN
    INSERT INTO students (name, age) VALUES (name, age) RETURNING id INTO new_id;
    RETURN new_id;
END;
$$ LANGUAGE plpgsql;

Se chiami questa funzione con dati sbagliati, tipo age < 0, ti dà errore. Miglioriamola con un po’ di debug.

Funzione migliorata con logging:

CREATE FUNCTION add_student(name TEXT, age INTEGER) RETURNS INTEGER AS $$
DECLARE
    new_id INTEGER;
BEGIN
    -- Logghiamo i dati di input
    RAISE NOTICE 'Aggiunta studente: nome %, età %', name, age;

    -- Controlliamo che l’età sia valida
    IF age < 0 THEN
        RAISE EXCEPTION 'L’età non può essere negativa!';
    END IF;

    -- Aggiungiamo lo studente e restituiamo il suo ID
    INSERT INTO students (name, age) VALUES (name, age) RETURNING id INTO new_id;

    -- Logghiamo il successo dell’operazione
    RAISE NOTICE 'Studente aggiunto con ID %', new_id;

    RETURN new_id;
END;
$$ LANGUAGE plpgsql;

Ora, se c’è un errore, saprai esattamente cosa è andato storto grazie ai messaggi stampati con RAISE NOTICE.

Consigli utili per finire

1. Non dimenticare di togliere i log inutili dal codice in produzione. RAISE NOTICE è uno strumento fantastico per il debug, ma se lo lasci ovunque rischi di riempire i log in produzione.
2. Lavora con pezzi di codice piccoli. Se la funzione è troppo complicata, dividila in più parti. Così il debug è più facile.
3. Allenati spesso. Più scrivi e fai debug, più diventi veloce a trovare e risolvere i bug.

Il debug è come fare il detective, solo che invece della lente d’ingrandimento hai query SQL e la logica di PL/pgSQL. La maestria arriva con l’esperienza, ma ogni bug risolto ti rende un po’ più forte!