Verschil tussen taal sql en taal plpgsql in PostgreSQL-functies

SQL-functies

... zijn de betere keuze:

• Voor eenvoudige scalaire zoekopdrachten . Niet veel te plannen, bespaar liever overhead.

• Voor enkele (of zeer weinig) oproepen per sessie . Er is niets te winnen bij plancaching via voorbereide statements die PL/pgSQL te bieden heeft. Zie hieronder.

• Als ze doorgaans worden aangeroepen in de context van grotere zoekopdrachten en eenvoudig genoeg zijn om inline te zijn .

• Bij gebrek aan ervaring met elke proceduretaal zoals PL/pgSQL. Velen kennen SQL goed en dat is ongeveer alles wat je nodig hebt voor SQL-functies. Weinigen kunnen hetzelfde zeggen over PL/pgSQL. (Hoewel het vrij eenvoudig is.)

• Een wat kortere code. Geen blokoverhead.

PL/pgSQL-functies

... zijn de betere keuze:

• Wanneer u procedurele elementen nodig heeft of variabelen die uiteraard niet beschikbaar zijn in SQL-functies.

• Voor elke vorm van dynamische SQL , waar je bouwt en EXECUTE verklaringen dynamisch. Speciale aandacht is nodig om SQL-injectie te voorkomen. Meer details:

  • Postgres-functies versus voorbereide zoekopdrachten

• Wanneer u berekeningen . heeft dat kan hergebruikt worden op verschillende plaatsen en een CTE kan daarvoor niet worden uitgerekt. In een SQL-functie heb je geen variabelen en zou je gedwongen worden om herhaaldelijk te rekenen of naar een tabel te schrijven. Dit gerelateerde antwoord op dba.SE heeft codevoorbeelden naast elkaar voor het oplossen van hetzelfde probleem met behulp van een SQL-functie / een plpgsql-functie / een query met CTE's:

  • Een parameter doorgeven aan een functie

Opdrachten zijn wat duurder dan in andere proceduretalen. Pas een programmeerstijl aan die niet meer opdrachten gebruikt dan nodig is.

• Wanneer een functie niet inline kan worden geplaatst en herhaaldelijk wordt aangeroepen. In tegenstelling tot SQL-functies, kunnen queryplannen in de cache worden opgeslagen voor alle SQL-statements binnen een PL/pgSQL-functie; ze worden behandeld als voorbereide verklaringen , wordt het plan in de cache opgeslagen voor herhaalde aanroepen binnen dezelfde sessie (als Postgres verwacht dat het in de cache opgeslagen (algemene) plan beter presteert dan elke keer opnieuw te plannen. Dat is de reden waarom PL/pgSQL-functies meestal sneller na de eerste paar telefoontjes in dergelijke gevallen.

  Hier is een draad over pgsql-performance waarin enkele van deze items worden besproken:

  • Re:pl/pgsql-functies presteren beter dan sql-functies?

• Wanneer u fouten moet opvangen .

• Voor triggerfuncties .

• Bij het opnemen van DDL-instructies objecten wijzigen of systeemcatalogi op enigerlei wijze wijzigen die relevant zijn voor volgende opdrachten - omdat alle instructies in SQL-functies tegelijk worden geparseerd terwijl PL/pgSQL-functies elke instructie opeenvolgend plannen en uitvoeren (zoals een voorbereide instructie). Zie:

  • Waarom kunnen PL/pgSQL-functies een neveneffect hebben, terwijl SQL-functies dat niet kunnen?

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