Version imprimable
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
Utilisez la fonction COALESCE...
A +
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
Super, merci de t'intéresser. Mais c'est pas tout à fait la réponse que j'attendais.Citation:
Envoyé par escartefigue
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...:?
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 :ccool:
C'est bien tordu comme problème, bravo à vous.Citation:
Envoyé par Sve@r
PostGreSQL a beaucoup de défaut en matière de typage... le plus étonant est le suivant :Citation:
Envoyé par Sve@r
Money et addition avec 1 :Code:
2
Money et multiplication avec 1 :Code:
2
3
4
5
6
7
Et plus généralement sur les problèmes de PG....Code:
2
3
4
5
6
7
8
9
10
11
12SELECT *, 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
A +
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é.
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).Code:
2
3
4
5
6
7
8
9
10
11
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 +
C'est dommage j'aime beaucoup PostgreSQL mais il semble qu'il prend des libertés avec la norme.Citation:
Envoyé par SQLpro
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.Citation:
Envoyé par Sve@r
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 +