PostgreSQL peut-il créer une base de données sensible à la casse?

Je porte du code d'une version de Sybase vers PostgreSQL. Il s'agit d'une application C qui utilise la bibliothèque client Sybase. Mon approche consiste à écrire une couche de traduction qui traduit les appels dbsqlexec()vers PQexec()(par exemple). Cette partie fonctionne principalement.

Il semble que la base de données Sybase soit configurée en respectant la casse (en ce qui concerne les noms d'objets de la base de données). Par exemple, il y a à la fois une WIDGETtable et une widgettable. Il semble que la convention dans cette application est que les noms en majuscules indiquent les tables de données réelles, tandis que les noms en minuscules sont utilisés comme tables temporaires lors de l'exécution de certains traitements.

Selon 4.1 Structure lexicale , «les mots clés et les identifiants sans guillemets ne respectent pas la casse. » Je sais que je peux citer des identifiants pour désactiver le pliage automatique en minuscules, mais je ne veux pas avoir à le faire manuellement à travers les millions de lignes de code qui utilise cette base de données.

Existe-t-il un moyen de configurer PostgreSQL pour désactiver ce pliage automatique des cas pour les identificateurs d'objets de base de données?

Mon alternative sera d'écrire du code qui examine chaque instruction SQL et met des guillemets autour de chaque identifiant (qui n'est pas un mot-clé).

postgresql case-sensitive

— Greg Hewgill
source

Les mots clés peuvent être utilisés comme identifiants s'ils sont placés entre guillemets doubles - même si vous ne devriez pas le faire. Dans tous les cas, vous ne pouvez pas être sûr que certains identifiants de votre base de code Sybase ne sont pas des mots clés dans PostgreSQL. Raison de plus pour citer deux fois les identifiants ou, de préférence, les renommer.

— Erwin Brandstetter

les identificateurs non cotés dans postgres ne sont en fait pas sensibles à la casse du tout, ils sont traités comme des minuscules. donc tAbLeNaMe correspondra à une seule table appelée nom de table mais pas à une table appelée nom de table. Je renommerais les tables car sinon les gens oublieraient le "et

— finiraient

@JamesRyan: c'est faux. select * from TaBlEnAmEréférencera la même table que select * from tablenameouselect * from TABLENAME

— a_horse_with_no_name

@a_horse_with_no_name: Si vous create table "tableName" (id integer primary key);, create table "tablename" (id integer primary key);puis cette requête select * from TaBlEnAmE;sélectionnera à partir de "nom de table", pas de "nom de table". "Les noms sans guillemets sont toujours pliés en minuscules" .

— Mike Sherrill 'Cat Recall'

J'ai fini par écrire du code qui transforme le SQL généré par l'application en SQL compatible PostgreSQL. C'est assez simple:

Divisez l'instruction en jetons sensibles, en ignorant les littéraux de chaîne entre guillemets simples
Citez tout ce qui n'est pas un mot-clé ou un nombre

J'ai également profité de cette couche pour transformer les appels isnullvers coalesce. Jusqu'à présent, cela fonctionne plutôt bien.

— Greg Hewgill
source

j'utilise des guillemets ("blahblablah") pour le rendre sensible à la casse .. cela fonctionne bien pour moi ..

— Anuj Patel

Existe-t-il un moyen de configurer PostgreSQL pour désactiver ce pliage automatique des cas pour les identificateurs d'objets de base de données?

Pas directement. Vous pourrez peut- être apporter une modification relativement mineure au code source de PostgreSQL et le recompiler. (Commencer dans src / backend / parser / parser.c?) Mais je serais surpris si c'était très simple.

— Mike Sherrill 'Cat Recall'
source

Je préfère ne pas jouer avec le code source, car cela nécessiterait une modification personnalisée de l'installation de PostgreSQL chaque fois que quelque chose changerait (hôte, version, etc.), et les installations binaires ne seraient pas disponibles.

— Greg Hewgill