Discussion :

[Plexi86]

Bonjour à tous.

Je vous explique la situation : suite à un upgrade de la version de PostgreSQL de la 8.2 à la 8.3, après restauration de mes BDD qui s'est bien déroulée, l'application web qui en dépend ne fonctionne plus. En fait il s'agit d'un problème dû à une requête du genre :

Code :

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

1
2
3
4
select exd.id,exd.node,
    exd.valid,(select codes.libelle from codes where codes.sous_cat='ACTI_RECH' and codes.code=exd.activite) as activite_lib,exd.activite,exd.nomempl
from exd where exd.node ILIKE '011A85P'

qui fait une comparaison d'égalité entre un champ de type character varying et un autre de type integer. D'où l'erreur:

ERREUR: l'opérateur n'existe pas : integer = character varying

Mon souci: c'est que cette requête se trouve dans une .ddl que je ne peux modifier, et la BDD ne doit subir aucun changement sur son dictionnaire de données (pas de alter column pour changer le type). L'application n'est pas de moi et je dois la reprendre pour des mises à jours. Ce qui me surprend c'est que cette requête ne posait aucun problème jusqu'à maintenant...

Alors je me demande comment Postgresql gérait cette conversion auparavant? faut-il activer quelque chose pour les conversion implicites, c'est la seule piste que j'ai, mais j'ai besoin d'avis d'experts.

Merci d'avance pour vos réponses.

Bonne journée.

[SQLpro]

Et bien vous êtes dans une impasse car les règles de transtypage étant plus ou moins libre, chaque SGBDR peut transtyper comme bon lui semble en l'absence de cohérence dans la requête et même changer le comportement d'une version à l'autre !

Seule solution : revenir à la version précédente.

Entre nous je fustigerait l'imbécile qui a écrit une requête aussi stupide (il suffirait d'ajouter un CAST pour que tout aile bien), comme celui qui a modélisé la base de données (les types doivent être cohérent pour les jointures) pour avoir sciemment ignoré ce qu'est un modèle de données !

A +

[estofilo]

faut-il activer quelque chose pour les conversion implicites

Il est possible de les créer soi-même avec CREATE CAST
Il existe un script qui recrée un partie des conversions implicites (voire toutes?) qui ont disparu en 8.3.

[Plexi86]

Je vous remercie pour vos réponses.

L'envie ne m'en manque pas, j'ignorais complétement, par principe d'ailleurs, qu'on pouvait tester une égalité sur deux arguments de types différents.
Je fais systématiquement mes cast personnellement, et là je viens de perdre une semaine pour cette bêtise...

Toutefois, merci pour le script estoFilo, il m'évite une réinstalle complète de la BDD.

Hors sujet: autre surprise: le champ incriminé de type text dans la Base de données, est lié en interface avec des champs de saisie qui n'autorisent que la saisie numérique ... Je le remercie pour la modélisation des données et du traitement, parce que bien sûr l'interface est un contrôle personnalisé répertorié dans une .dll!!
Estimation du temps de redéveloppement pour une demande d'évolution: ... juste pour une conversion où une requête SQL aurait suffit, on se retrouve à faire de la maintenance sur la BDD, faire les conversions et refaire l'application, sans savoir qu'est-ce qui va être impacté au final.

Le pire c'est que je commence à avoir l'habitude de récupérer les plans comme ça, je ne fais plus que de la maintenance à force...