Forskellen mellem sprog sql og sprog plpgsql i PostgreSQL-funktioner

SQL-funktioner

... er det bedre valg:

• Til simple skalære forespørgsler . Der er ikke meget at planlægge, men det er bedst at spare eventuelle omkostninger.

• For enkelt (eller meget få) opkald pr. session . Intet at vinde ved plancaching via forberedte erklæringer, som PL/pgSQL har at tilbyde. Se nedenfor.

• Hvis de typisk kaldes i forbindelse med større forespørgsler og er enkle nok til at blive inlinet .

• I mangel på erfaring med ethvert proceduresprog som PL/pgSQL. Mange kender SQL godt, og det er omtrent alt hvad du behøver til SQL-funktioner. Få kan sige det samme om PL/pgSQL. (Selvom det er ret simpelt.)

• Lidt kortere kode. Ingen blok overhead.

PL/pgSQL-funktioner

... er det bedre valg:

• Når du har brug for procedureelementer eller variabler som naturligvis ikke er tilgængelige i SQL-funktioner.

• Til enhver form for dynamisk SQL , hvor du bygger og EXECUTE udsagn dynamisk. Særlig omhu er nødvendig for at undgå SQL-injektion. Flere detaljer:

  • Postgres-funktioner kontra forberedte forespørgsler

• Når du har beregninger der kan genbruges flere steder og en CTE kan ikke strækkes til formålet. I en SQL-funktion har du ikke variabler og ville være tvunget til at beregne gentagne gange eller skrive til en tabel. Dette relaterede svar på dba.SE har side-by-side kodeeksempler for at løse det samme problem ved hjælp af en SQL-funktion / en plpgsql-funktion / en forespørgsel med CTE'er:

  • Sådan overføres en parameter til en funktion

Opgaver er noget dyrere end på andre processprog. Tilpas en programmeringsstil, der ikke bruger flere opgaver end nødvendigt.

• Når en funktion ikke kan indlejres og kaldes gentagne gange. I modsætning til SQL-funktioner kan forespørgselsplaner cachelagres for alle SQL-sætninger inde i en PL/pgSQL-funktion; de behandles som forberedte udtalelser , cachelagres planen for gentagne opkald inden for samme session (hvis Postgres forventer, at den cachelagrede (generiske) plan yder bedre end at planlægge om hver gang. Det er grunden til, at PL/pgSQL-funktioner typisk er hurtigere efter de første par opkald i sådanne tilfælde.

  Her er en tråd om pgsql-performance, der diskuterer nogle af disse emner:

  • Vedr.:pl/pgsql-funktioner, der overgår sql-funktioner?

• Når du har brug for at fælde fejl .

• Til triggerfunktioner .

• Når du inkluderer DDL-sætninger, ændrer du objekter eller ændrer systemkataloger på nogen måde, der er relevant for efterfølgende kommandoer - fordi alle sætninger i SQL-funktioner parses på én gang, mens PL/pgSQL-funktioner planlægger og udfører hver sætning sekventielt (som en forberedt sætning). Se:

  • Hvorfor kan PL/pgSQL-funktioner have bivirkning, mens SQL-funktioner ikke kan?

Overvej også:

• PostgreSQL Stored Procedure Performance

For faktisk at vende tilbage fra en PL/pgSQL-funktion kan du skrive:

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

Der er andre måder:

• Kan jeg få en plpgsql-funktion til at returnere et heltal uden at bruge en variabel?
• Manualen om "Tilbage fra en funktion"