Differenza tra linguaggio sql e linguaggio plpgsql nelle funzioni PostgreSQL

Funzioni SQL

... sono la scelta migliore:

• Per query scalari semplici . Non c'è molto da pianificare, meglio risparmiare le spese generali.

• Per singole (o pochissime) chiamate per sessione . Niente da guadagnare dalla memorizzazione nella cache del piano tramite istruzioni preparate che PL/pgSQL ha da offrire. Vedi sotto.

• Se vengono in genere chiamati nel contesto di query più grandi e sono abbastanza semplici da essere inline .

• Per mancanza di esperienza con qualsiasi linguaggio procedurale come PL/pgSQL. Molti conoscono bene SQL e questo è tutto ciò di cui hai bisogno per le funzioni SQL. Pochi possono dire lo stesso di PL/pgSQL. (Anche se è piuttosto semplice.)

• Codice un po' più breve. Nessun sovraccarico del blocco.

Funzioni PL/pgSQL

... sono la scelta migliore:

• Quando hai bisogno di qualsiasi elemento procedurale o variabili che non sono disponibili nelle funzioni SQL, ovviamente.

• Per qualsiasi tipo di SQL dinamico , dove costruisci ed EXECUTE affermazioni in modo dinamico. È necessaria una cura speciale per evitare l'iniezione di SQL. Maggiori dettagli:

  • Funzioni Postgres vs query preparate

• Quando hai calcoli che può essere riutilizzato in più punti e un CTE non può essere allungato per lo scopo. In una funzione SQL non hai variabili e saresti costretto a calcolare ripetutamente o scrivere su una tabella. Questa risposta correlata su dba.SE ha esempi di codice affiancati per risolvere lo stesso problema utilizzando una funzione SQL / una funzione plpgsql / una query con CTE:

  • Come passare un parametro in una funzione

Gli incarichi sono leggermente più costosi rispetto ad altri linguaggi procedurali. Adatta uno stile di programmazione che non utilizzi più compiti del necessario.

• Quando una funzione non può essere incorporata e viene chiamata ripetutamente. A differenza delle funzioni SQL, è possibile memorizzare nella cache i piani di query per tutte le istruzioni SQL all'interno di una funzione PL/pgSQL; sono trattati come dichiarazioni preparate , il piano viene memorizzato nella cache per le chiamate ripetute all'interno della stessa sessione (se Postgres prevede che il piano (generico) memorizzato nella cache funzioni ogni volta meglio della ripianificazione. Ecco perché le funzioni PL/pgSQL sono tipicamente più veloci dopo le prime due chiamate in questi casi.

  Ecco un thread su pgsql-performance che discute alcuni di questi elementi:

  • Re:funzioni pl/pgsql che superano quelle sql?

• Quando hai bisogno di intercettare gli errori .

• Per funzioni di attivazione .

• Quando si includono istruzioni DDL che cambiano oggetti o alterano i cataloghi di sistema in qualsiasi modo rilevanti per i comandi successivi, perché tutte le istruzioni nelle funzioni SQL vengono analizzate contemporaneamente mentre le funzioni PL/pgSQL pianificano ed eseguono ciascuna istruzione in sequenza (come un'istruzione preparata). Vedi:

  • Perché le funzioni PL/pgSQL possono avere effetti collaterali, mentre le funzioni SQL no?

CREATE FUNCTION f2(istr varchar)
  RETURNS text AS
$func$
BEGIN
   RETURN 'hello! ';  -- defaults to type text anyway
END
$func$ LANGUAGE plpgsql;