Enregistrements basés sur le curseur dans PostgreSQL

1. Curseur implicite

Il est presque toujours préférable d'utiliser le curseur implicite d'un FOR boucle que de recourir à un curseur explicite un peu plus lent et peu maniable. J'ai écrit des milliers de fonctions plpgsql et seulement une poignée de fois des curseurs explicites avaient un sens.

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;

A part :il n'y a rien dans la fonction qui aurait besoin de volatilité VOLATILE . Utilisez STABLE .

2. Approche basée sur les ensembles

Il est presque toujours préférable d'utiliser une approche basée sur les ensembles si possible . Utilisez RETURN QUERY pour retourner comme défini à partir d'une requête directement.

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. Fonction SQL

Pour le cas simple (probablement une simplification), vous pouvez également utiliser une fonction SQL simple ou même simplement la requête :

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;