Discussion :

[mercure07]

Bonjour tout le monde, je débute avec PostrgeSQL et dés le départ je rencontre un gros problème. En fait, j'ai quelques 104 procédures a adapter et tester sous Postgres mais je viens de m'appercevoir que PorstGeSQL n'effectue de cast automatique. Cela est vraiment contraignant vu que je dois faire des cast dans les procédures et cela va nécessiter un temps inutile.
Voila l'erreur que j'ai obtenu en exécutant ma 1ère procédure :

Code :

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

operator does not exist: integer = character varying

Y a t il un patch ou un paramètrage particulier qui peuvent remèdier à ce problème.
Merci d'avance.
Cordialement.

[SQLpro]

Non, il n'y a pas de transtypage automatique et les règles de transtypage sont données par la norme SQL qui considère toujours que l'on doit "trantyper au plus large" ce qui signifie qu'entre un type numérique et une chaine de caractères, c'est la chaîne de caractères qui l'emporte.

A +

[scheu]

Concernant les conversions de types sur Postgresql c'est assez vicieux, généralement il vaut toujours mieux éviter qu'elles soient implicites, notamment quand on développe en PL/PgSQL par exemple
Les indexes ne peuvent pas toujours être utilisés si par exemple on fait "where col_date = '20080101' " par exemple

[say]

Je remonte le post pour approfondir.

Nous venons de migrer de PGSQL 8.1 à la 8.3.7...et là oh désespoir...plus d'implicit cast... 3 ans de dév foutus en l'air (j'exagère à peine)

Il est dès lors possible de créer des cast soi-même.

sauf que je m'en sors pas... j'ai prévu ce qui suit :

Code :

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

1
2
3
4
5
6
7
8
9
 
CREATE OR REPLACE FUNCTION text(timestamp with time zone) RETURNS text
    AS $$ BEGIN
                RETURN CAST($1 as text);
        END;
$$ LANGUAGE plpgsql;
 
CREATE CAST (timestamp with time zone as text) with
function  text(timestamp with time zone) as implicit;

l'idée étant de ne pas avoir à faire ça par exemple :

Code :

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

select to_date(now()::text,'YYYY-MM-DD')

une fois le cast créé, j'ai un message de dépassement de pile (max_stack_depth), qu'est ce que j'ai foiré dans ma fonction?

merci d'avance

[say]

http://wiki.postgresql.org/images/d/...icit-casts.sql

[scheu]

Nous venons de migrer de PGSQL 8.1 à la 8.3.7...et là oh désespoir...plus d'implicit cast... 3 ans de dév foutus en l'air (j'exagère à peine)

Au delà de ton erreur le problème c'est qu'avec des fonctions de cast partout les indexes risquent de ne plus pouvoir être utilisés dans les plans d'exécution

Une migration de version Postgresql ne doit jamais se faire en big-bang "from scratch" sans aucun test préalable. Il faut impérativement bien recetter l'appli sur la nouvelle version justement pour éviter les problèmes de perfs ou même les erreurs de syntaxe qui ne passent plus ... et pouvoir corriger le SQL et Pg/SQL

La compatibilité ascendante entre les versions de Postgresql est toujours délicate, il y a justement sur le site officiel les "notes de version" qui parlent des ces différences de comportement

Si vraiment ton appli ne marche plus du tout niveau syntaxes et/ou perfs, je te conseille fortement de faire retour arrière sur une 8.1, et de bien préparer la migration en 8.3.7 avec une recette
Les modifications à apporter au dév existant peuvent être conséquentes en nombre de jours/hommes, surtout si tu as des conversions implicites partout dans tes procédures stockées PL/PgSQL ...

[say]

Alors,

Dans l'absolu, je suis archi d'accord..tests et recettage.
en fait, nous n'avions encore jamais pris le temps de migrer pgsql (notamment à cause de composants tiers qui nous posaient problème), et nous ne nous attendions pas à une compatibilité ascendante comme celle-ci...qui reste cependant explicite et louable.

Pour ce qui est du recettage, comme tu le dis, les J/H peuvent exploser...et donc tout dépend de la structure : nous sommes 3 ;-)
retourner en 8.1...galère, notamment car nous voulions migrer en 8.3 pour passer en cluster avec pgpool ( et pouvoir rattacher les noeuds à chaud).

Quoi qu'il en soit, nous avons créer nos casts.... et nous aviserons pas la suite



C'était plus un cri de désespoir. ;-)

[scheu]

Si tu utilises des fonctions cast dans tes requêtes, fait bien attention aux plans d'exécution, il se peut que des indexes utilisés auparavant ne le soient plus si tu utilises des fonctions sur tes colonnes, et il se peut que tu aies des problèmes de performances liés à celà

Il faudra peut-être que tu crées des indexes fonctionnels dans ce cas

Bon courage en tout cas