Discussion :

[Sve@r]

Bonjour à tous

Est-il possible de demander qu'une colonne prenne sa valeur par défaut dans une fonction plpgsql ?

Genre j'ai une fonction "xxx()" qui retourne une chaine, et ma colonne serait alors créée ainsi nom char(20) default xxx() (à l'instar des colonnes qui prennent leur valeur dans la fonction "nextval()" d'une séquence et qui s'écrivent alors ... default nextval('nom_sequence')) ???

Merci à tous

[SQLpro]

Utilisez la fonction COALESCE...

A +

[escartefigue]

Bonsoir,

Pour qu'une colonne prenne sa valeur par défaut, il suffit de ne pas la citer dans l'ordre INSERT.
On peut également utiliser le mot clef DEFAULT si la colonne est citée.


Exemple ICI

[Sve@r]

Pour qu'une colonne prenne sa valeur par défaut, il suffit de ne pas la citer dans l'ordre INSERT

Super, merci de t'intéresser. Mais c'est pas tout à fait la réponse que j'attendais.
Mon souci se situe (ou plutôt se situait car depuis j'ai trouvé) dans la création de la colonne. J'ai défini une fonction xxx(n) qui renvoie une chaine aléatoire de n caractères, et je voulais que lors du insert, quand effectivement on ne cite pas la colonne comme tu proposes, celle-ci appelle xxx() par défaut pour avoir une valeur aléatoire (pour créer des jeux d'essais).
Quand j'ai écrit ce topic je n'y arrivais pas et j'ai cru que ça venait de l'impossibilité d'associer ce défault à xxx().
En réalité le souci venait du fait que j'écrivais nom char(20) default xxx(20) mais la fonction xxx() prend un smallint en paramètre et 20 est un integer (pas souple le truc).

Donc en écrivant nom char(20) default xxx(20::smallint) ça passe.

PS: on a aussi le droit de citer la colonne en l'associant au mot spécial "default" dans les datas à insérer.

Merci aussi pour la proposition de coalesce mais je vois pas trop son utilité. Ca serait nom char(20) default coalesce(xxx(20)) ? Mais la fonction est faite pour éliminer les nullls or il n'y a aucun null dans l'insert...

[escartefigue]

Ah ok, l'essentiel est que ce soit résolu et merci d'avoir donné la solution pour ceux qui seraient confrontés au même besoin

[Waldar]

En réalité le souci venait du fait que j'écrivais nom char(20) default xxx(20) mais la fonction xxx() prend un smallint en paramètre et 20 est un integer (pas souple le truc).
Donc en écrivant nom char(20) default xxx(20::smallint) ça passe.

C'est bien tordu comme problème, bravo à vous.

[SQLpro]

...
En réalité le souci venait du fait que j'écrivais nom char(20) default xxx(20) mais la fonction xxx() prend un smallint en paramètre et 20 est un integer (pas souple le truc).

Donc en écrivant nom char(20) default xxx(20::smallint) ça passe....

PostGreSQL a beaucoup de défaut en matière de typage... le plus étonant est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CREATE TABLE T_DES_SOUS (MONTANT money);
INSERT INTO T_DES_SOUS  VALUES (1), (5.5), (-3);

Money et addition avec 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT *, MONTANT * 1 AS PLUS
FROM   T_DES_SOUS;
 
montant	PLUS
1,00 €	1,00 €
5,50 €	5,50 €
-3,00 €	-3,00 €

Money et multiplication avec 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SELECT *, MONTANT + 1
FROM   T_DES_SOUS

ERROR:  l'opérateur n'existe pas : money + integer
LINE 1: SELECT *, MONTANT + 1
                          ^
HINT:  Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type. 

ERREUR:  l'opérateur n'existe pas : money + integer
SQL state: 42883
Character: 19

Et plus généralement sur les problèmes de PG....

A +

[Sve@r]

Tu as inversé les titres (le premier c'est la multiplication et tu l'as titré "addition" et pareil pour l'autre)
Ceci dit je ne trouve pas ça vraiment étonnant. Multiplier un "money" n fois finalement c'est juste additionner des money ensembles or additionner des money c'est pas plus compliqué qu'additionner des oranges.
Tandis qu'additionner "money" et "int" je comprends que ça n'ait pas été programmé. Ca aurait pu (on peut dire que l'int c'est un money sans décimal) mais cela ne l'a pas été.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
postgres=# select 1.5::money * 2;
 ?column? 
----------
   3,00 €
(1 row)
 
postgres=# select 1.5::money + 2.5::money;
 ?column? 
----------
   4,00 €
(1 row)

En Python il y a des choses analogues. On peut multiplier des strings ("abc" * 3 donne "abcabcabc"), on peut aussi les additionner ("abc" + "de" donne "abcde") mais on ne peut pas additionner une string et un int. Peut-être pour ça que je ne trouve pas ça tellement surprenant. Et certainement moins surprenant qu'une fonction incapable de faire rentrer un int dans un smallint en laissant de côté ce qui dépasse (le C le fait de façon naturelle et Postgres a été écrit en C).

[SQLpro]

La norme SQL (SQL est un langage normalisé) impose un haut niveau de transtypage, le type de données ne devant pourvoir ne jamais être connu de l'écriture de requêtes...
En cette matière tous les SGBDR savent la pratiquer sauf PostGreSQL.

Le fonctionnement des SGBD Relationnel, qui diffèrent grandement des langages applicatif est basé sur la sémantique et non le typage. Ainsi la chaine de caractères 'bonjour monde' qu'elle soit encodée en ASCII, UTF8, UTF16, UCS2 doit répondre "VRAI" dès lors qu'elle est comparée avec le même contenu quelque soit l'encodage de part et d'autre du comparateur "=". Il en va de même pour les nombres.

En gros, la norme SQL précise que tous les types de données de la famille des nombres, la comparaison doit être directe. Ce n'est hélas pas le cas de PostGreSQL... mais tous les autres SGBDR la respecte.... !

A +

[Sve@r]

...En cette matière tous les SGBDR savent la pratiquer sauf PostGreSQL....Ce n'est hélas pas le cas de PostGreSQL... mais tous les autres SGBDR la respecte.... !

C'est dommage j'aime beaucoup PostgreSQL mais il semble qu'il prend des libertés avec la norme.
On avait déjà eu une discussion il y a quelque temps à propos de contraintes qui doivent avoir un nom unique dans la base mais que Postgres a décidé de limiter le nom unique au schéma ce qui m'obligeait à passer par les tables pg_xxx pour récupérer les contraintes et non par les tables "officielles" (enfin c'est vieux donc peut-être que je retranscris mal mais j'espère que tu te souviens, tu avais même ouvert un ticket sur le site de Postgres directement et je crois qu'ils t'avaient envoyé te faire ballader et tu avais alors conclu un truc comme "Postgres se dit 100% conforme à la norme mais on constate qu'il ne l'est pas").
Après bon je m'y adapte (et je continue à l'aimer quand-même)...

[SQLpro]

C'est dommage j'aime beaucoup PostgreSQL mais il semble qu'il prend des libertés avec la norme.
On avait déjà eu une discussion il y a quelque temps à propos de contraintes qui doivent avoir un nom unique dans la base mais que Postgres a décidé de limiter le nom unique au schéma ce qui m'obligeait à passer par les tables pg_xxx pour récupérer les contraintes et non par les tables "officielles" (enfin c'est vieux donc peut-être que je retranscris mal mais j'espère que tu te souviens, tu avais même ouvert un ticket sur le site de Postgres directement et je crois qu'ils t'avaient envoyé te faire ballader et tu avais alors conclu un truc comme "Postgres se dit 100% conforme à la norme mais on constate qu'il ne l'est pas").
Après bon je m'y adapte (et je continue à l'aimer quand-même)...

Même constat.... Le discours est en décalage avec la réalité. Le SGBDR sans doute le plus conforme à la norme est IBM DB2.... Pas de difficultés car IBM est l'inventeur du langage SQL ! Suivi de Microsoft SQL Server. Depuis que MS a repris SQL Server de Sybase, il n'arrêtent pas de le mettre dans le bon chemin de la norme SQL. Les bons derniers sont Oracle et MySQL/MariaDB dont les libertés les font dérivés fortement de la norme.

En ce qui concerne PostGreSQL il y a eu quelques erreurs par rapport à la norme et depuis plus de 10 ans, l'incapacité de suivre les nouveautés de la norme SQL, car cela demande une effort de R&D énorme. Un petit exemple, l'absence de tables temporelles tel que la norme l'a prévu en 2015...
http://mssqlserver.fr/wp-content/upl...mmentaires.pdf

Mais dans le libre c'est ce qu'il y a de mieux ! Cela ne m'empêche pas de le critiquer, comme je critique Oracle ou SQL Server. Il est en effet plus important de connaître les limites d'un système (donc les points bloquants) que d'en connaître toutes les fonctionnalités dès que l'on démarre un projet. Dans ma carrière j'ai trop souvent vu se planter des projets, avec des conséquences gravissimes (morts...) indirectement pas un mauvais choix.... Mais je suis un vieu con, dont la retraite est proche !

A +