Discussion :

[CinePhil]

Bonjour,
Après avoir fait toute la structure de ma première base de données Postgresql en écrivant des noms de tables et de colonnes avec des lettres capitales (Film, Artiste, Document, Doc_Film, F_Id, F_TitreFrancais...), j'ai essayé d'insérer un premier enregistrement en PHP / PDO avec une requête toute simple en SQL standard :

Code :

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

1
2
INSERT INTO CineDoc.Pays(P_Code, P_NomFrancais, P_NationaliteMAsc, P_NationaliteFem)
VALUES('FR', 'France', 'français', 'française')

Et j'ai eu la désagréable surprise de découvrir, après quelques recherches sur le web, que ma requête ne pouvait pas fonctionner car Postgresql met automatiquement tous les noms d'objets en minuscules, sauf s'ils sont entourés de guillemets.

Du coup, les requêtes deviennent beaucoup plus chiantes à écrire en PHP, avec les apostrophe ou guillemets qui entourent le texte de la requête.

N'y aurait-il pas un paramètre de Postgresql qui l'empêcherait de faire ce qu'on ne lui demande pas, c'est à dire l'empécher de transformer le texte de la requête selon son bon plaisir ?

[estofilo]

Un paramètre dans ce genre n'est pas réellement envisageable, parce qu'à partir du moment où les colonnes sont définies en gardant la casse, ce qui est un choix explicite à la création de la table par l'usage de guillemets autour des noms de colonne, il est alors possible d'écrire:

Code :

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

create table matable ("Colonne1" int, colonne1 int)

Et on a bien 2 colonnes différentes.
Mais si par la suite on activait le paramètre hypothétique "case insensitive" et qu'on faisait

Code :

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

select colonne1 from matable

, comment le serveur pourrait-il savoir de quelle colonne on parle?

[CinePhil]

Le but n'est pas d'avoir 2 colonnes ou tables de même nom, ce qui ne m'arrive jamais car je préfixe toujours mes noms d'objets, mais de pouvoir écrire les noms avec des majuscules sans guillemets dans les requêtes et que Postgresql ne les transforme pas en minuscules et ne comprenne plus ce que je lui écris.

Si j'en crois SQLPro :

Les noms des objets sont-ils sensibles à la casse ?

La norme SQL dit que par principe, les noms des objets SQL (nom de table, de vue, de colonne...) ne sont pas sensible à la casse.

Faut-il que je refasse toute ma base de données ?
Elle est encore vide (1 seule ligne insérée) donc c'est encore faisable mais ça fait chier !

[xavier-Pierre]

bonjour ,
il suffit d'ecrire toutes tes requetes en miniscule

[estofilo]

En effet par défaut les noms ne sont pas sensibles à la casse, que ce soit avec PG ou avec d'autres SGBD comme Oracle.

Ce qui est curieux c'est que ton script de création (ou l'outil que tu utilises si tu passes par un outil) utilise explicitement des guillemets pour demander justement au serveur de ne pas respecter cette règle par défaut, et que aussitôt après tu t'en plains en disant que tu voulais exactement le contraire. Mais le serveur ne fait que respecter ton choix de départ, qui est une décision irréversible.

Enfin sauf évidemment à recréer les objets sans aucun guillemet nulle part, ce qui est à mon avis la meilleure chose à faire si tu n'es pas trop avancé dans le projet.

[CinePhil]

J'ai utilisé PGAdmin pour créer les tables et c'est lui qui a écrit les requêtes de création avec les guillemets.
Bon ben je crois que je vais refaire la BDD parce qu'en PHP ça va être trop galère en utilisation.

Il y a une requête magique pour récupérer le SQL de création de toute la BDD ?

[estofilo]

Il y a une requête magique pour récupérer le SQL de création de toute la BDD ?

La commande

Code :

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

pg_dump --schema-only

[Arkhena]

Si j'en crois SQLPro :

Effectivement, voilà ce que j'ai trouvé dans la norme :

An <SQL language identifier> is equivalent to an <SQL language identifier> in which every letter that is
a lower-case letter is replaced by the corresponding upper-case letter or letters. This treatment includes
determination of equivalence, representation in the Information and Definition Schemas, representation in
diagnostics areas, and similar uses.

(p.153 du lexical element du brouillon de la norme SQL:2003, trouvé ici)

Remarquez comme c'est joliement dit et comment on peut éviter l'usage des termes "case insensitive" qui permettraient de comprendre trop rapidement ce qu'on veut dire!

Cordialement,

Arkhena

[SQLpro]

Remarquez comme c'est joliement dit et comment on peut éviter l'usage des termes "case insensitive" qui permettraient de comprendre trop rapidement ce qu'on veut dire!

Moi qui travaille avec la norme à longueur de temps, je me permet de vous signaler que cela n'est pas si simple.
En effet la notion de casse d'un point de vue technique ne signifie pas majuscule ou minuscule, mais la situation des caractères aux plomb dans l'outil. Or il n'y a pas que les majuscule et les minuscules. Il y a aussi une typographie oubliée dans le vocabulaire, mais bien présente pour les typographe, celle des lettres capitales, qui sont différentes des majuscule et des minuscules...
http://marcautret.free.fr/sigma/pratik/typo/majcaps/
Il semble donc que la définition de ce qu'est la casse soit donc plus complexe que le simple fait de dire que la représentation d'une même lettre de l'alphabet quelque soit sa "graphie" sera considérée comme équivalent... Du coup ne trouvez vous pas cette dernière définition plus simple ?

A +