Coder en PL/pgSQL sans passer par la création d'une fonction

guk92 · 20/10/2011 19:47:40

Bonsoir,

Je souhaiterais savoir s'il existe un moyen de coder en PL/pgSQL sans passer par la création de fonction.
Je souhaiterais en faite effectuer des tests, m'entrainer à pratiquer le langage, mais à chaque fois je dois passer par la création d'une fonction de test.

Existe-t-il un moyen de faire du PL/pgSQL sans créer de fonction ?

Je vous remercie

rjuju · 20/10/2011 20:00:45

Bonsoir.
Non, il n'est hélas pas possible de faire ça.

Cela dit la syntaxe de création d'une fonction n'est pas ce qui vous prendra le plus de temps dans le développement

Un petit lien pour les astuces de développement en Pl/PgSQL :
http://docs.postgresql.fr/9.1/plpgsql-d … -tips.html

Dernière modification par rjuju (20/10/2011 20:01:03)

guk92 · 20/10/2011 22:04:00

Oui c'est habituellement ce que je fais, j'utilise un éditeur de texte coloré (très pratique), j'utilise aussi les symboles $ pour créer ou remplacer une fonction.

Au début, quand j'ai vu l'erreur, je me suis posé des questions parce qu'on peut coder en T-SQL sans créer de fonction sous SQL Server, mais après j'ai compris

1. J'ai vu que PostgreSQL permettait de coder en C, Perl, Python etc... y a t-il beaucoup de personne codant avec ces langages ?
Je veux dire par là que bien que je sache coder en C par exemple, je ne l'utiliserais pas pour créer des fonctions, j'utiliserais sans hésiter le PL/pgSQL.

J'ai lu quelque part qu'il existait le SQL/PSM, je connais très peu d'information là-dessus, je sais juste que c'est un langage normalisé (en 2003, donc récent) et qu'il était équivalent au T-SQL / PL/SQL / PL/pgSQL.

J'ai trouvé ce document qui parle du SQL/PSM, et j'ai été étonné de voir que c'est MySQL qui l'implémente (moi qui cherchait à connaitre le nom du langage utilisé par MySQL je ne suis pas déçu ).

Pour finir j'ai lu cette autre lien, qui dit que PostgreSQL implémente ce langage depuis 2007 (c'est très récent), mais je n'ai rien vu de tel sur internet.

2. J'ai trouvé très peu d'information sur le SQL/PSM. Pourquoi parles-t-on très peu du SQL/PSM ?
3. Est-ce que PostgreSQL intègre ou va intégrer ce langage ? (car je sais que PostgreSQL respecte au mieux les normes)
Si oui, va-t-on continuer avec le PL/pgSQL ou mettre en avant le SQL/PSM ?

Ce qui pourrait être pratique avec un langage normalisé tel que le SQL/PSM, c'est que nous n'aurions pas autant de langages, je ne vous cache pas que ça commence à devenir très commercial entre T-SQL, PL/SQL, Progress etc...

Merci

rjuju · 20/10/2011 22:42:16

1. J'ai vu que PostgreSQL permettait de coder en C, Perl, Python etc... y a t-il beaucoup de personne codant avec ces langages ?

Coder en pl/c permet d'avoir un gros gain de performance, accès à beaucoup plus de fonctionnalités (création d'aggrégats par exemple) mais on perd une certaine souplesse, code compilé spécifique à une plateforme, il faut recompiler pour en changer voire faire des adaptations, pas de visibilité du code en direct etc.
Pour le perl, python etc ça permet d'avoir plus de liberté sur le serveur (gestion de fichier etc) et de garder un langage qu'on aime pour le faire, avec encore une fois plus de performance.
La plupart des contrib sont codés dans ces langages (les langages visible dans le fichier sql d'installation si vous êtes curieux)

Pour le reste, désolé mais je n'y connais rien ^^

Dernière modification par rjuju (20/10/2011 22:43:04)

guk92 · 20/10/2011 23:27:28

Rjuju a écrit :

c permet d'avoir un gros gain de performance [...] code compilé

Moi je pensais que tout ces langages qu'on utilisait pour créer une fonction ou procédure PostgreSQL étaient interprétés et donc tous équivalent...

Rjuju a écrit :

on perd une certaine souplesse, code compilé spécifique à une plateforme, il faut recompiler pour en changer voire faire des adaptations

Mon maitre d'apprentissage m'avait dit que les SGBD avait un "OS" en interne (et donc qu'avec un peu de débrouillardise on pourrait même avoir "SQL Server sous du Linux" par exemple ), il disait souvent des bêtises et j'en ai hérité aussi
4. N'est ce pas PostgreSQL qui "compile" le code en interne du coup ? (toute plateforme confondu)

Avant de m'attaquer au PL/pgSQL, je m'étais d'abord intéressé au C (vu que je connaissais le C), mais je me suis très vite perdu.
5. Pourriez-vous me montrer un exemple simple de CREATE FUNCTION en C qui contient une requête SQL ?
J'en ai malheureusement pas trouvé sur internet.

Merci

Dernière modification par guk92 (20/10/2011 23:43:49)

rjuju · 21/10/2011 00:00:49

Je crois que les procédures pl/pgsql sont compilées en interne par Postgresql au premier appel et à chaque fois qu'elles sont modifiées, sans doute quelqu'un de plus connaisseur sur ces points techniques pourra vous le confirmer ou en dire plus. En tout cas ce code est bien sur multi plateforme.

Les procédure en pl/c sont utilisée via des fichiers binaires (.dll, .so), donc du code compilé.
Pour les autres langages (pl/perl etc) je n'ai jamais eu l'occasion d'en utiliser et ne m'avancerai donc pas.

Pour apprendre à faire du pl/c, la doc officielle donne une très bonne base de départ pour ça : http://docs.postgresql.fr/9.1/xfunc-c.html
Cela dit, il y a vraiment un gain à faire une procédure en pl/c s'il y a beaucoup de calculs et traitements internes, une simple suite d'appels à des requêtes ne changera presque rien.

Dernière modification par rjuju (21/10/2011 00:05:29)

dverite · 21/10/2011 00:20:44

guk92 a écrit :

Existe-t-il un moyen de faire du PL/pgSQL sans créer de fonction ?

Oui, à partir de la 9.0 avec la commande DO:

http://docs.postgresqlfr.org/9.0/sql-do.html

Marc Cousin · 21/10/2011 10:28:44

Y a un paquet de questions dans le thread. Je vais essayer d'y répondre

- Oui, la bonne syntaxe pour faire du PL sans créer de fonctions, c'est DO
- C est de loin le plus rapide :il est compilé, c'est une des raisons. mais aussi le fait qu'il n'y a pas autant de conversions à faire entre les types natifs de PostgreSQL et les types du langage (passer un array à Perl, c'est un peu plus sportif, dans le code de plperl), un interpréteur perl ou python ou autre à faire tourner et à qui passer les infos, etc… Par contre, en C, un segfault est si vite arrivé. Et un segfault d'un backend (processus dans lequel PostgreSQL traite les requêtes), c'est redémarrage de toute l'instance, pour ne pas risquer de corruptions de données. C'est pour ça que le PL/C est surtout utilisé pour les modules contrib, qui sont bien testés en amont. En ce qui me concerne, je me suis déjà servi du PL/C pour programmer un type de données compressé par un algorithme de Huffman, pour un champ texte dont je connaissais la répartition statistique à l'avance. C'est vraiment à limiter à ce genre de choses… bas niveau
- Le PL/PgSQL est compilé à la première exécution dans sa session. Sauf les requêtes qu'il contient, qui sont préparées (calcul de plan d'exécution) au moment de leur première exécution. Et ça va être un peu plus compliqué en 9.2 (il essayera de déterminer après quelques exécutions si il vaut mieux un plan générique ou un plan préparé à chaque exécution de la requête)
- Pour un exemple de fonction en C, regardez dans les sources du répertoire contrib de PostgreSQL, il y en a plusieurs

gleu · 21/10/2011 12:19:28

Concernant SQL/PSM, si, Pavel Stehule travaille sur ce langage pour l'intégrer à PostgreSQL. À ma connaissance, il n'y a rien de vraiment prêt pour l'instant.

guk92 · 21/10/2011 16:59:34

Merci à tous pour vos réponses

En effet DO est très pratique pour faire du PL/pgSQL sans avoir à créer de fonction.
La syntaxe pour faire du C me paraît un poil compliqué, je m'y lancerais dedans si c'est vraiment nécessaire un jour.

Pour ce qui est du SQL/PSM j'ai voulu m'intéresser à sa syntaxe de plus prêt en consultant la doc MySQL... pas terrible en faite :
- Pour ce qui est des conditions IF / ELSIF / ELSE, c'est la même chose que le PL/pgSQL (avec "ELSEIF" et pas "ELSIF").
- Pour le WHILE il suffit juste de remplacer LOOP [...] END LOOP du PL/pgSQL par DO [...] END WHILE.
- La syntaxe du LOOP est vraiment nulle, vous devez impérativement créer un label pour quitter une boucle infinie avec la commande LEAVE label, en PL/pgSQL EXIT suffit.
- Il n'y a pas de boucle FOR, celui-ci est remplacé par un équivalent : REPEAT
- Une nouvelle instruction apparait, ITERATE : "Refaire une boucle" WHILE | REPEAT | LOOP en cours lorsqu'une condition est vraie.
- Pour tout les boucles (WHILE | REPEAT | LOOP) il est possible de créer des labels, je pense que c'est même conseillé.
- L'instruction CASE reste identique
- Enfin, comme avec le T-SQL, il existe une syntaxe pour les procédures et une autre pour les fonctions.

Par contre j'aurais une dernière question, concernant les variables dans les procédures, en faite j'ai voulu créer un petit programme utilisant une procédure stockée qui contient une requête (je souhaiterais donc récupérer la valeur de plusieurs colonnes d'une requête), j'ai donc fais ceci :

DO $$
DECLARE var1 integer;
DECLARE var2 integer;
BEGIN
SELECT MIN(val) INTO var1 FROM t1; -- Pas d'erreur
SELECT MIN(val) INTO var1, MAX(val) FROM t1; -- Pas d'erreur
SELECT MIN(val) INTO var1, MAX(val) INTO var2 FROM t1; -- ERREUR
END;
$$

Donc je ne peux pas faire de SELECT... INTO plus d'une seule fois !
J'ai aussi essayé avec l'affectation ( := ) mais ça ne fonctionne pas.

J'ai donc vu cette exemple sur internet.
6. Peut-t-on réellement mettre en paramètre d'une fonction le nom des colonnes d'une requête comme dans l'exemple?
(c'est la première fois que je vois cette manière de procéder).
7. Quel est la syntaxe à adopter pour créer une procédures stockées contenant une requête dont les valeurs des colonnes vont servir dans un programme (Java, PHP, Python etc...) ?

Je vous remercie

gleu · 21/10/2011 22:54:38

Donc je ne peux pas faire de SELECT... INTO plus d'une seule fois !

Non, c'est plutôt que vous n'avez pas utilisé une syntaxe correcte. Il faudrait faire ceci : SELECT MIN(val), MAX(val) INTO var1, var2 FROM t1;

Peut-t-on réellement mettre en paramètre d'une fonction le nom des colonnes d'une requête comme dans l'exemple?

C'est possible sur les versions antérieures à la 9.0 mais non recommandé. C'est impossible par défaut sur les versions 9.0 et ultérieures.

Quel est la syntaxe à adopter pour créer une procédures stockées contenant une requête dont les valeurs des colonnes vont servir dans un programme (Java, PHP, Python etc...) ?

Il faudrait préciser la question car j'avoue que je ne comprends pas ce que vous voulez faire.

guk92 · 22/10/2011 01:54:32

Merci Gleu, les deux premières réponses répondent en faite à la troisième question.
Je cherchais en faite à récupérer plusieurs valeurs d'une requêtes lors d'un appel de procédures stockées dans un programme codé en PHP (voir exemple n°4 et 5).
J'ai déjà vu des exemples avec une seule valeur, mais je ne connaissais pas la syntaxe lorsqu'on a plus d'une valeur.
Je vais donc tester cela (SELECT ... INTO).

Je vous remercie pour toutes ces réponses.

Dernière modification par guk92 (22/10/2011 01:56:05)

SQLpro · 22/10/2011 12:14:31

guk92 a écrit :

J'ai lu quelque part qu'il existait le SQL/PSM, je connais très peu d'information là-dessus, je sais juste que c'est un langage normalisé (en 2003, donc récent) et qu'il était équivalent au T-SQL / PL/SQL / PL/pgSQL.

Probablement dans mon livre sur SQL... SQL, collection Synthex - Pearson Education
Petite précision : SQL/PSM est l'ensemble de la norme SQL qui spécifie les "Persistent Stored Module" (ISO/IEC 9075-4 - Part 4 : Persistent Stored Modules (SQL/PSM)), c'est à dire tout ce qui est code persistant dans la base, autrement dit les procédures stockées, les fonctions utilisateurs (UDF) et les déclencheurs.
Autrement dit n'importe quel SGBDR qui fait des procédures stockées, peut se réclamer PSM... Sauf que la plupart des implémentations de PSM sont non standards et donc pas portable d'un SGBDR à l'autre. Le SGBDR le plus proche de la norme SQL étant, encore aujourd"hui IBM DB2 UDB.

Enfin, oui, hélas, il n'est pas possible de faire des batch avec PG comme on le fait avec SQL Server ou Oracle, et c'est dommage !

A +

gleu · 22/10/2011 19:00:23

Enfin, oui, hélas, il n'est pas possible de faire des batch avec PG comme on le fait avec SQL Server ou Oracle, et c'est dommage !

Faux, on peut faire des batchs depuis la version 9.0 (voir instruction DO - http://docs.postgresql.fr/9.1/sql-do.html), ce que d'ailleurs ont indiqué dverite, Marc et guk92.

SQLpro · 24/10/2011 12:39:11

ha parfait, je n'avais pas encore vu cela... Dommage que vous n'en ayez pas trop parlé dans vos présentation de la version 9... Ou bien j'ai raté quelque chose...

A +

gleu · 24/10/2011 13:09:47

Je ne sais pas à quel document vous faites référence. Voici ceux que je connais :

* c'est sur le document français des nouveautés de la version 9.0 écrit par Marc Cousin : http://blog.postgresql.fr/index.php?pos … ostgreSQL2
* c'est sur le document des nouveautés de la version 9.0 dans le wiki de postgresql.org (traduction du document français, qui a ensuite été amélioré si je ne me trompe pas) : http://wiki.postgresql.org/wiki/What%27 … _Blocks.29
* c'est sur l'article de GLMF écrit par moi-même : http://www.dalibo.org/glmf134_postgresq … veautes#do
* c'est sur la slide 12 de http://www.dalibo.org/quoi_de_neuf_dans_postgresql_9 (slides écrites par Marc)

Et tous en parlent

#1 20/10/2011 19:47:40

Coder en PL/pgSQL sans passer par la création d'une fonction

#2 20/10/2011 20:00:45

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#3 20/10/2011 22:04:00

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#4 20/10/2011 22:42:16

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#5 20/10/2011 23:27:28

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#6 21/10/2011 00:00:49

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#7 21/10/2011 00:20:44

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#8 21/10/2011 10:28:44

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#9 21/10/2011 12:19:28

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#10 21/10/2011 16:59:34

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#11 21/10/2011 22:54:38

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#12 22/10/2011 01:54:32

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#13 22/10/2011 12:14:31

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#14 22/10/2011 19:00:23

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#15 24/10/2011 12:39:11

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

#16 24/10/2011 13:09:47

Re : Coder en PL/pgSQL sans passer par la création d'une fonction

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux