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.

[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

[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 ?

[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 +

[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

[CinePhil]

Réponse de pg_admin :

ERROR: syntax error at or near "pg_dump"
LIGNE 1 : pg_dump --schema-only

[estofilo]

pg_dump est l'outil de sauvegarde standard de PG, c'est une commande externe appelable à partir du shell qui est totalement indépendante de pgadmin3

[CinePhil]

Oui j'ai trouvé dans pg_admin la rubrique de menu Outils/Sauvegarder.

Par contre, j'ai supprimé tous les guillemets du fichier texte engendré par pg_dump puis j'ai voulu restaurer le schéma mais pg_admin a refusé en disant qu'il lui semblait que ce n'était pas un fichier de sauvegarde.

Du coup, j'ai passé les requêtes du fichier par petits blocs, en ajoutant le nom du schéma dans toutes les requêtes sinon il faisait les créations de tables et autres objets dans le schéma public.

J'avais aussi créé un domaine 'sexe' qui n'a pas été sauvegardé et que j'ai dû recréer pour qu'une création de table de personnes fonctionne.

Même avec les requêtes écrites en majuscules sans guillemets, tous les objets ont été créés avec des noms en minuscules !
Bref j'ai galéré toute la soirée pour refaire ma BDD et elle n'est pas comme j'aurais voulu. Mais bon ce sera plus facile pour écrire les requêtes en PHP ensuite.

Pas top cette histoire de majuscules/minuscules sur Postgresql !

[CinePhil]

Je viens de faire un test...

J'ai créé une table en écrivant la requête tout en majuscules sans guillemets
==> la table, ses colonnes, ses contraintes ont des noms en minuscules

J'ai inséré des données avec l'interface de PGAdmin.

J'ai lancé une requête, tout en majuscules sans guillemets, du genre :

Code :

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

SELECT * FROM LATABLE

==> J'ai eu le résultat, probablement parce que la requête a été transformée en minuscules et qu'il a donc trouvé les objets.

J'ai essayé aussi en mélangeant majuscules et minuscules sans guillemets :

Code :

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

SELECT * FROM LaTable

==> Résultat idem.

C'est un moindre mal mais je trouve quand même bizarre qu'on ne puisse pas exiger de Postgresql qu'il respecte notre manière d'écrire !