Discussion :

[Shonagon]

Bonjour,
Je réalise actuellement une migration de serveur qui s'accompagne d'une upgarde de version de PostGresSQL (7.0.3 -> 8.0.8). Il ya évidemment des petits soucis m'enfin on finit par trouver une solution. Sauf que là j'ai un gros soucis.
Ma base initiale comporte une table nommée "analyse" et cela pose problème.
Ainsi, il ne m'est pas possible de faire une requête de type :
SELECT* FROM analyse
[Message d'erreur : erreur de syntaxe sur ou près de «analyse»]
En revanche
SELECT * FROM "analyse"
fonctionne.

Cette nécessité de devoir mettre des guillemets n'est valable que pour la table "analyse". Aucun problème pour les autres tables.
J'envisage donc de faire la modif dans les scripts, c'est-à- direr ajouter des guillemets . Mais plus j'évalue la tâche à réaliser, plus j'ai des sueurs froides. Ce n'est pas tant l'occurence d'"analyse" qui me gêne mais le fait qu'il y a de nombreuses classes et fonctions générant des requêtes (avec des trucs du genre $table) et que là ça complique sévèrement. Bref pour pas faire de bêtise je vais devoir vérifier le code sur de multiples scripts. Et la tâche se révèle himalayenne.
Tout ça parce que le moteur PostgreSQL semble coincer sur un nom de table analyse et son emploi sans guillemets dans une requête SQL.
Alors je me demande s'il n'y a pas une solution plus simple au problème. Une configuration de PostgreSQL ou quelque chose comme ça.
Si vous avez des idées. Merci !

[Shonagon]

Ouf... Il y avait plus simple.

Presque toutes les requêtes passent via une fonction. Je n'en avais pendant longtemps pas vu l'utilité ( juste écrire query($sql) au lieu de pg_exec($con,$sql) ), mais là, elle m'a économisé beaucoup beaucoup de crampes de clavier.

Et voilà, un petit coup d'expression régulière et le tour est joué.

Code :

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

1
2
3
4
5
 
function query($sql) {
  $sql = ereg_replace(" (analyse)([\., ])"," \"\\1\"\\2",$sql);
...
}