1. Impliciete cursor
Het is bijna altijd beter om de impliciete cursor van een FOR
. te gebruiken lus dan om zijn toevlucht te nemen tot een wat langzamere en onhandige expliciete cursor. Ik heb duizenden plpgsql-functies geschreven en slechts een handvol keren expliciete cursors had enige zin.
CREATE OR REPLACE FUNCTION avoidable_states()
RETURNS SETOF varchar AS
$func$
DECLARE
rec record;
BEGIN
FOR rec IN
SELECT *
FROM address ad
JOIN city ct USING (city_id)
LOOP
IF rec.city LIKE '%hi%' THEN
RETURN NEXT rec.city;
END IF;
END LOOP;
END
$func$ LANGUAGE plpgsql STABLE;
Terzijde:er is niets in de functie dat volatiliteit nodig zou hebben VOLATILE
. Gebruik STABLE
.
2. Set-gebaseerde benadering
Het is bijna altijd beter om indien mogelijk een set-gebaseerde benadering te gebruiken . Gebruik RETURN QUERY
om rechtstreeks vanuit een zoekopdracht terug te keren als ingesteld.
CREATE OR REPLACE FUNCTION avoidable_states()
RETURNS SETOF varchar AS
$func$
BEGIN
RETURN QUERY
SELECT ct.city
FROM address ad
JOIN city ct USING (city_id)
WHERE ct.city LIKE '%hi%';
END
$func$ LANGUAGE plpgsql STABLE;
3. SQL-functie
Voor het eenvoudige geval (waarschijnlijk een vereenvoudiging), kunt u ook een eenvoudige SQL-functie gebruiken of zelfs alleen de query:
CREATE OR REPLACE FUNCTION avoidable_states()
RETURNS SETOF varchar AS
$func$
SELECT ct.city
FROM address ad
JOIN city ct USING (city_id)
WHERE ct.city LIKE '%hi%';
$func$ LANGUAGE sql STABLE;