PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 08/11/2010 12:44:16

FNo
Membre

Pb de varchar sur la 9.0.1

Bonjour,
Venant juste de passer de la 8.4 à la 9.0, je viens de rencontrer un petit soucis. Une fonction en Plpgsql doit retourner un type de données propriétaire. Ce type comporte un varchar(n). Dans la fonction , le retour se fait, après concaténation de chaînes, par un cast varchar. Voici les déclarations :

CREATE TYPE my_type AS (a int2,b varchar(61), c int2);

CREATE OR REPLACE FUNCTION my_fonction(integer, integer, integer,boolean) RETURNS SETOF my_type AS '
.
.
.
for my_record in select ...., (ch1 ||'' ''||ch2)::varchar ....


Et voici le message d'erreur obtenu avec cette nouvelle version :

Returned type character varying does not match expected type character varying(61) in column 2

Si je remplace par (ch1 ||'' ''||ch2)::varchar(61) cela fonctionne. Mais là n'est pas le but car il faudrait vérifier l'ensemble des fonctions et programmes. Je ne comprends pas le pourquoi, surtout que cette erreur n'est présente qu'en 9.0 et que cette syntaxe me semble correcte.

Merci si vous avez une idée sur la question.

Hors ligne

#2 08/11/2010 14:06:13

gleu
Administrateur

Re : Pb de varchar sur la 9.0.1

Un cast vers varchar() et un cast vers varchar(61) ne sont pas du tout identiques. Dans le premier cas, je peux avoir autant de caractères que je le souhaite alors que dans le second, je suis limité à 61. Le message d'erreur est donc logique. La différence entre les versions est certainement dû au travail effectué pour améliorer une vérification stricte des types.


Guillaume.

Hors ligne

#3 08/11/2010 16:08:55

FNo
Membre

Re : Pb de varchar sur la 9.0.1

Pourtant il me semble bien que la norme SQL prévoies le troncage. Il s'agit, tout de même, du même type fondamental.  Alors pourquoi en ligne de commande, un  select ('test'::varchar)::varchar(3); passe correctement en renvoyant 'tes' ? Est-ce à cause du traitement de la fonction que la logique diffère ?

Hors ligne

#4 08/11/2010 16:14:25

Marc Cousin
Membre

Re : Pb de varchar sur la 9.0.1

SQL prévoit le contrôle. Il n'y a que MySQL qui tronque des données sans vous le dire. Les autres refusent d'intégrer la donnée. Il s'agit de l'intégrité de vos données, et peu de SGBD le prennent à la légère. Vous lui annoncez qu'une chaîne ne doit pas dépasser 61 caractères, il vous prévient si vous essayez de violer cette contrainte.


Marc.

Hors ligne

#5 08/11/2010 16:19:03

gleu
Administrateur

Re : Pb de varchar sur la 9.0.1

Et pour répondre à la question "pourquoi en ligne de commande, un  select ('test'::varchar)::varchar(3); passe correctement en renvoyant 'tes' ?", tout simplement parce que vous forcez la conversion, contrairement au premier cas.


Guillaume.

Hors ligne

#6 08/11/2010 16:31:00

FNo
Membre

Re : Pb de varchar sur la 9.0.1

Merci à vous pour ces promptes précisions.
Juste un petit clin d'oeil à la documentation sur les varchar(n) :

An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length

Pas si clean que cela wink

Hors ligne

#7 08/11/2010 16:36:10

gleu
Administrateur

Re : Pb de varchar sur la 9.0.1

Pas si clean que cela

PostgreSQL ne peut rien y faire. Cette étrangeté est requise par la norme SQL.


Guillaume.

Hors ligne

#8 08/11/2010 16:44:27

Marc Cousin
Membre

Re : Pb de varchar sur la 9.0.1

Oui, les caractères blanc et les chaînes vides ont souvent des traitements un peu étranges. Et ce n'est pas le cas que pour la norme SQL…

Je présume que c'est là pour faciliter la compatibilité avec les vieux système (en Cobol par exemple) qui avaient des enregistrements de taille fixe et faisaient du padding avec des blancs. Mais c'est vrai que c'est une des saletés de la norme SQL.


Marc.

Hors ligne

Pied de page des forums