Skillnad mellan språk sql och språk plpgsql i PostgreSQL-funktioner

... är det bättre valet:

För enkla skalära frågor . Inte mycket att planera, bättre spara eventuella omkostnader.
För enkla (eller väldigt få) samtal per session . Inget att vinna på plancache via förberedda uttalanden som PL/pgSQL har att erbjuda. Se nedan.
Om de vanligtvis anropas i samband med större frågor och är enkla nog att infogas .
I brist på erfarenhet med något procedurspråk som PL/pgSQL. Många kan SQL väl och det är ungefär allt du behöver för SQL-funktioner. Få kan säga detsamma om PL/pgSQL. (Även om det är ganska enkelt.)
Lite kortare kod. Inget block över huvudet.

... är det bättre valet:

När du behöver några procedurelement eller variabler som inte är tillgängliga i SQL-funktioner, uppenbarligen.
För alla typer av dynamisk SQL , där du bygger och EXECUTE uttalanden dynamiskt. Särskild försiktighet krävs för att undvika SQL-injektion. Mer information:
- Postgres-funktioner kontra förberedda frågor
När du har beräkningar som kan återanvändas på flera ställen och en CTE kan inte sträckas för ändamålet. I en SQL-funktion har du inga variabler och skulle tvingas beräkna upprepade gånger eller skriva till en tabell. Det här relaterade svaret på dba.SE har sida vid sida kodexempel för att lösa samma problem med en SQL-funktion / en plpgsql-funktion / en fråga med CTE:er:
- Hur man skickar en parameter till en funktion

Uppdrag är något dyrare än på andra procedurspråk. Anpassa en programmeringsstil som inte använder fler uppdrag än nödvändigt.

När en funktion inte kan infogas och anropas upprepade gånger. Till skillnad från SQL-funktioner kan frågeplaner cachelagras för alla SQL-satser i en PL/pgSQL-funktion; de behandlas som förberedda uttalanden , cachelagras planen för upprepade samtal inom samma session (om Postgres förväntar sig att den cachade (generiska) planen ska fungera bättre än att planera om varje gång. Det är anledningen till att PL/pgSQL-funktioner är vanligtvis snabbare efter de första par samtalen i sådana fall.

Här är en tråd om pgsql-performance som diskuterar några av dessa saker:
- Angående:pl/pgsql-funktioner som överträffar sql-funktionerna?
När du behöver fälla fel .
För triggerfunktioner .
När du inkluderar DDL-satser ändrar objekt eller ändrar systemkataloger på något sätt som är relevant för efterföljande kommandon - eftersom alla satser i SQL-funktioner tolkas på en gång medan PL/pgSQL-funktioner planerar och exekverar varje sats sekventiellt (som en förberedd sats). Se:
- Varför kan PL/pgSQL-funktioner ha biverkningar, medan SQL-funktioner inte kan?

Tänk också på:

Att faktiskt återvända från en PL/pgSQL-funktion kan du skriva:

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

Det finns andra sätt:

Kan jag få en plpgsql-funktion att returnera ett heltal utan att använda en variabel?
Handboken om "Återgå från en funktion"