Linguaggi procedurali

La prova di PostgreSQL procede con i linguaggi procedurali.
A parte alcune originalità nella gestione delle transazioni all'interno delle procedure plpgsql (somigliano molto a quelle PL/SQL di Oracle), come l'impossibilità di usare savepoint, rollback ecc., e la mancanza di una gestione descrittiva degli errori, per il resto il linguaggio nativo è molto molto flessibile, come il resto del db! :-)
Per la produzione usiamo molto Python, un linguaggio di scripting relativamente semplice e potentissimo; in postgres è possibile usarlo come linguaggio per scrivere le funzioni.
Durante le prove siamo già arrivati a fare mostrare la corda a Python: abbiamo generato, non volontariamente, un bel SIGSEV (segnale 11 sotto Linux) in una sessione.
Molto interessante il comportamento di PostgreSQL in questi casi: il processo padre di quello andato in segmentation fault, accortosi della situazione critica, obbliga tutti gli altri processi ad un rollback collettivo, quindi fa un reset a caldo in pochi istanti (penso meno di un secondo).
Questo può sembrare un comportamento strano, ma è perfettamente giustificabile: il processo padre, non potendo sapere nulla dello stato della transazione del processo bombato, per mantenere la consistenza dei dati obbliga tutti ad abbandonare le modifiche in corso; diversamente sarebbe stato se, invece di ritornare con un segnale 11, il processo figlio avesse generato un errore, del tipo di un 'eccezione Python: sarebbe avvenuto solo un rollback della transazione corrente e nessuno si sarebbe accorto di nulla, come abbiamo provato successivamente.
Il discorso per mysql è molto diverso: reset del server, con chiusura totale, probabilmente senza flush dei dati verso il disco; non essendoci le transazioni, l'integrità dei dati è una bella incognita.