Prepared statement
Pattern SQL: si invia un modello di query con dei segnaposto ($1, ?) e si passano i parametri separatamente. Due vantaggi principali: protezione dalla SQL injection (i parametri non vengono mai interpretati come SQL) e caching del piano di esecuzione.
Ciclo di vita: PREPARE (invio del modello, entrano in azione parser e planner) → EXECUTE (invio dei valori, esecuzione del piano). Con il plan caching le chiamate successive saltano parsing e pianificazione e vanno direttamente all'esecuzione. Compromesso: il planner crea un piano generico, che può essere subottimale per valori specifici. PostgreSQL: dopo 5 chiamate con piano generico verifica se un piano personalizzato sarebbe migliore. Problema con i connection pool: i prepared statement sono legati alla sessione, quindi se le connessioni del pool sono condivise globalmente vengono ripreparati spesso. PgBouncer in modalità transaction li rompe.