Documentation PostgreSQL 14.22 » Programmation serveur » PL/pgSQL -- Langage de procédures SQL » Astuces pour développer en PL/pgSQL

Précédent | Niveau supérieur | Suivant
43.11. Les dessous de PL/pgSQL | Sommaire | 43.13. Portage d'Oracle PL/SQL

## 43.12. Astuces pour développer en PL/pgSQL

Un bon moyen de développer en PL/pgSQL est d'utiliser l'éditeur de texte de votre choix pour créer vos fonctions, et d'utiliser psql dans une autre fenêtre pour charger et tester ces fonctions. Si vous procédez ainsi, une bonne idée est d'écrire la fonction en utilisant `CREATE OR REPLACE FUNCTION`. De cette façon vous pouvez simplement recharger le fichier pour mettre à jour la définition de la fonction. Par exemple :

    CREATE OR REPLACE FUNCTION fonction_test(integer) RETURNS integer AS $$
    	  ....
    $$ LANGUAGE plpgsql;

Pendant que psql s'exécute, vous pouvez charger ou recharger des définitions de fonction avec :

    \i nom_fichier.sql

puis immédiatement soumettre des commandes SQL pour tester la fonction.

Un autre bon moyen de développer en PL/pgSQL est d'utiliser un outil d'accès à la base de données muni d'une interface graphique qui facilite le développement dans un langage de procédures. Un exemple d'un tel outil est pgAdmin, bien que d'autres existent. Ces outils fournissent souvent des fonctionnalités pratiques telles que la détection des guillemets ouverts et facilitent la re-création et le débogage des fonctions.

### 43.12.1. Utilisation des guillemets simples (quotes)

Le code d'une fonction PL/pgSQL est spécifié dans la commande `CREATE FUNCTION` comme une chaîne de caractères. Si vous écrivez la chaîne littérale de la façon ordinaire en l'entourant de guillemets simples, alors tout guillemet simple dans le corps de la fonction doit être doublé ; de la même façon, les antislashs doivent être doublés (en supposant que la syntaxe d'échappement de chaînes est utilisée). Doubler les guillemets devient rapidement difficile et, dans la plupart des cas compliqués, le code peut devenir rapidement incompréhensible parce que vous pouvez facilement vous trouver avec une douzaine, voire plus, de guillemets adjacents. À la place, il est recommandé d'écrire le corps de la fonction en tant qu'une chaîne littérale « avec guillemets dollar » (voir la Section 4.1.2.4). Dans cette approche, vous ne doublez jamais les marques de guillemets mais vous devez faire attention à choisir un délimiteur dollar différent pour chaque niveau d'imbrication dont vous avez besoin. Par exemple, vous pouvez écrire la commande `CREATE FUNCTION` en tant que :

    CREATE OR REPLACE FUNCTION fonction_test(integer) RETURNS integer AS $PROC$
       ....
    $PROC$ LANGUAGE plpgsql;

À l'intérieur de ceci, vous pouvez utiliser des guillemets pour les chaînes littérales simples dans les commandes SQL et `$$` pour délimiter les fragments de commandes SQL que vous assemblez comme des chaînes. Si vous avez besoin de mettre entre guillemets du texte qui inclut `$$`, vous pouvez utiliser `$Q$`, et ainsi de suite.

Le graphe suivant montre ce que vous devez faire lors de l'écriture de guillemets simples sans guillemets dollar. Cela pourrait être utile lors de la traduction de code avec guillemets simples en quelque chose de plus compréhensible.

1 guillemet simple

  Pour commencer et terminer le corps de la fonction, par exemple :

      CREATE FUNCTION foo() RETURNS integer AS '
      	.....
      ' LANGUAGE plpgsql;

  Partout au sein du corps de la fonction entouré de guillemets simples, les guillemets simples doivent aller par paires.

2 guillemets simples

  Pour les chaînes de caractères à l'intérieur du corps de la fonction, par exemple :

      une_sortie := ''Blah'';
      SELECT * FROM utilisateurs WHERE f_nom=''foobar'';

  Dans l'approche du guillemet dollar, vous devriez juste écrire :

      une_sortie := 'Blah';
      SELECT * FROM utilisateurs WHERE f_nom='foobar';

  ce qui serait exactement ce que l'analyseur PL/pgSQL verrait dans les deux cas.

4 guillemets simples

  Quand vous avez besoin d'un guillemet simple dans une chaîne constante à l'intérieur du corps de la fonction, par exemple :

      une_sortie := une_sortie || '' AND nom LIKE ''''foobar'''' AND xyz''

  La valeur effectivement concaténée à `une_sortie` est : `AND nom LIKE 'foobar' AND xyz`.

  Dans l'approche du guillemet dollar, vous auriez écrit :

      une_sortie := une_sortie || $$ AND nom LIKE 'foobar' AND xyz$$

  Faites attention que chaque délimiteur en guillemet dollar ne soient pas simplement `$$`.

6 guillemets simples

  Quand un simple guillemet dans une chaîne à l'intérieur du corps d'une fonction est adjacent à la fin de cette chaîne constante, par exemple :

      une_sortie := une_sortie || '' AND nom LIKE ''''foobar''''''

  La valeur effectivement concaténée à `une_sortie` est alors : `AND nom LIKE 'foobar'`.

  Dans l'approche guillemet dollar, ceci devient :

      une_sortie := une_sortie || $$ AND nom LIKE 'foobar'$$

10 guillemets simples

  Lorsque vous voulez deux guillemets simples dans une chaîne constante (qui compte pour huit guillemets simples) et qu'elle est adjacente à la fin de cette chaîne constante (deux de plus). Vous n'aurez probablement besoin de ceci que si vous écrivez une fonction qui génère d'autres fonctions comme dans l'Exemple 43.10. Par exemple :

      une_sortie := une_sortie || '' if v_'' ||
          referrer_keys.kind || '' like ''''''''''
          || referrer_keys.key_string || ''''''''''
          then return ''''''  || referrer_keys.referrer_type
          || ''''''; end if;'';

  La valeur de `une_sortie` sera alors :

      if v_... like ''...'' then return ''...''; end if;

  Dans l'approche du guillemet dollar, ceci devient :

      une_sortie := une_sortie || $$ if v_$$ || referrer_keys.kind || $$ like '$$
      || referrer_keys.key_string || $$'
      then return '$$  || referrer_keys.referrer_type
      || $$'; end if;$$;

  où nous supposons que nous avons seulement besoin de placer des marques de guillemets simples dans `une_sortie` parce que les guillemets seront recalculés avant utilisation.

### 43.12.2. Vérifications supplémentaires à la compilation et à l'exécution

Pour aider l'utilisateur à trouver les problèmes simples mais fréquents avant qu'ils ne posent de vrais problèmes, PL/PgSQL fournit des `vérifications` supplémentaires. Une fois activées, suivant la configuration, elles peuvent être utilisées pour émettre soit un `WARNING` soit un `ERROR` pendant la compilation d'une fonction. Une fonction qui a reçu un `WARNING` peut être exécutée sans produire d'autres messages, mais vous êtes averti de la tester dans un environnement de développement séparé.

Positionner `plpgsql.extra_warnings` ou `plpgsql.extra_errors`, selon les cas, à `"all"` est encouragé dans les environnements de développement et de test.

Ces vérifications supplémentaires sont activées via les variables de configuration `plpgsql.extra_warnings` pour les messages d'avertissement et `plpgsql.extra_errors` pour les erreurs. Les deux peuvent être configurés soit avec une liste de vérifications séparées par des virgules, soit pour aucune (`"none"`), soit pour toutes (`"all"`). La valeur par défaut est `"none"`. Actuellement la liste des vérifications possibles comprend :

`shadowed_variables`

  Vérifie si une déclaration cache une variable définie précédemment.

`strict_multi_assignment`

  Certaines commandes PL/PgSQL permettent d'affecter des valeurs à plus d'une variable à la fois, comme `SELECT INTO`. Typiquement, le nombre de variables cibles et le nombre de variables sources devraient correspondre, même si PL/PgSQL utilise `NULL` pour les valeurs manquantes et que les variables en excès sont ignorées. Le fait d'autoriser ce test fera que PL/PgSQL provoquera un avertissement (`WARNING`) ou une erreur (`ERROR`) si jamais les nombres de variables cibles et sources sont différents.

`too_many_rows`

  L'activation de ce test fait que PL/PgSQL vérifie si une requête utilisée avec un clause `INTO` renvoie plus d'une ligne. Comme une instruction avec `INTO` ne prendra en compte qu'une seule ligne, le fait d'avoir une requête qui en retourne plusieurs est généralement inefficace et/ou non-déterministe et par conséquent est probablement une erreur.

L'exemple suivant montre l'effet de `plpgsql.extra_warnings` configuré à `shadowed_variables` :

    SET plpgsql.extra_warnings TO 'shadowed_variables';

    CREATE FUNCTION foo(f1 int) RETURNS int AS $$
    DECLARE
    f1 int;
    BEGIN
    RETURN f1;
    END;
    $$ LANGUAGE plpgsql;
    WARNING:  variable "f1" shadows a previously defined variable
    LINE 3: f1 int;
            ^
    CREATE FUNCTION

L'exemple suivant montre l'effet de `plpgsql.extra_warnings` configuré à `strict_multi_assignment` :

    SET plpgsql.extra_warnings TO 'strict_multi_assignment';

    CREATE OR REPLACE FUNCTION public.foo()
     RETURNS void
     LANGUAGE plpgsql
    AS $$
    DECLARE
      x int;
      y int;
    BEGIN
      SELECT 1 INTO x, y;
      SELECT 1, 2 INTO x, y;
      SELECT 1, 2, 3 INTO x, y;
    END;
    $$;

    SELECT foo();
    WARNING:  number of source and target fields in assignment does not match
    DETAIL:  strict_multi_assignment check of extra_warnings is active.
    HINT:  Make sure the query returns the exact list of columns.
    WARNING:  number of source and target fields in assignment does not match
    DETAIL:  strict_multi_assignment check of extra_warnings is active.
    HINT:  Make sure the query returns the exact list of columns.

     foo
    -----

    (1 row)