2014-04-26 1 views
0

J'ai une application qui fonctionne très bien sur Postgres 9.0, mais après la mise à niveau vers la version 9.3, une énorme instruction SQL a cessé de fonctionner. Mon hypothèse est que le comportement pg est passé d'insensible à la casse à sensible à la casse. Voici la déclaration qui travaille sur pg 9.0, mais renvoie une erreur sur 9.3:PostgreSQL traitant l'identificateur de cas sensible après la mise à niveau de 9.0 à 9.3?

> ERROR: column tmplrole.name does not exist at character 35 

La requête:

select cftCE.f_resource as ceId, tmplRole.name as tRole, mdtk.meta_type_key as metaKey, md1.metadatum_value as metaValue, grp1.id as groupId 
from account acc1 
left outer join account_role accRole on acc1.f_principal=accRole.f_account 
left outer join roles r1 on accRole.f_role=r1.f_principal 
left outer join template_role tmplRole on r1.f_template_role=tmplRole.id 
left outer join groups grp1 on r1.f_group=grp1.id left outer join content_entry cftCE on grp1.f_content_entry=cftCE.f_resource 
left outer join metadatum md1 on cftCE.f_resource=md1.f_content_entry 
left outer join meta_type mdtk on md1.f_meta_type=mdtk.id 
inner join (select f_content_entry as permCe from groups grp 
inner join (select f_group as groupId from operation opr  
inner join (select ppr.f_resource as cftce from PRINCIPAL_PERMISSION_RESOURCE ppr  
inner join (select roles.f_principal as userrole from roles, account_role, account  
where roles.f_principal=account_role.F_role and account_role.f_account=account.f_principal and account.f_principal=$1) 
AS roles_alias on ppr.f_principal = userrole  
inner join (select operation.f_resource as viewCftOperation from Operation where Operation.F_TEMPLATE_OPERATION=$2) 
AS operation_alias on ppr.f_resource = viewCftOperation) AS ppr_alias on opr.F_resource = cftce) 
AS group_alias on grp.ID = groupid) 
AS content_entry_alias on cftCE.f_resource = permCe where acc1.f_principal=$3 
and (mdtk.meta_type_key=$4 or mdtk.meta_type_key=$5 or mdtk.meta_type_key=$6) order by cftCE.date_created desc; 
+1

Regardez (et après, le cas échéant) la définition de votre table pour la solution. –

+0

Comment avez-vous migré de 9.0 à 9.3? –

+0

Le comportement n'a certainement pas ** changé ** d'une version à l'autre. Vous avez probablement créé les tables en utilisant des guillemets doubles. Voir la manua: http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS –

Répondre

3

règles de la sensibilité de cas ont pas changé, mais le traitement des tablename.type a changé dans PostgreSQL 9.1. Le hic est que name est un type intégré postgres, utilisé pour le catalogue.

est ici l'entrée correspondante dans le 9.1 release notes:

E.14.2.2. Coulée
Disallow fonction de style et type de données de type d'attribut pour jette types composites (Tom Lane)

Par exemple, n'autorise pas composite_value.text et le texte (composite_value). Les utilisations involontaires de cette syntaxe ont souvent abouti à des rapports de bug ; Bien que ce n'était pas un bug, il semble préférable de revenir à en rejetant de telles expressions. Les syntaxes CAST et :: sont toujours disponibles lorsqu'une distribution d'une valeur composite entière est en réalité .

Je dirais que votre table template_role n'a pas de name colonne 9.0, et ayant tmplRole.name être interprété comme tmplRole::name était un bug a été passé inaperçu dans votre requête.

Voir aussi la concernant Is name a special keyword in PostgreSQL?

+1

Belle prise! Une autre raison pour laquelle 'name' n'est pas un bon nom. –

+0

Merci Daniel, vous avez raison tout le problème était dans cette construction dans le nom de type qui a été retiré de postgres 9.1 – user3576027

Questions connexes