2010-12-06 62 views
22

J'utilise PostgreSQL v9.0.1 avec Rails (et il est DEPS) @v2.3.8, en raison de l'utilisation de la capacité texte intégral de postgres, j'ai une table qui est définie comme:ERREUR: Vous devez être propriétaire de la langue plpgsql

 
CREATE TABLE affiliate_products (
    id integer NOT NULL, 
    name character varying(255), 
    model character varying(255), 
    description text, 
    price numeric(9,2), 
    created_at timestamp without time zone, 
    updated_at timestamp without time zone, 
    textsearch_vector tsvector, 
); 

Notez la dernière ligne, cela s'assure que l'enregistrement actif n'est pas capable de le traiter avec le dumper de schéma standard, donc je dois définir config.active_record.schema_format = :sql dans ./config/environment.rb; et utilisez rake db:test:clone_structure au lieu de rake db:test:clone.

Rien de tout cela est trop remarquable, seul inconvénient - mais rake db:test:clone_structure échoue avec l'erreur:

ERROR: must be owner of language plpgsql

En raison de la ligne #16 dans mon résultat ./db/development_schema.sql:

CREATE OR REPLACE PROCEDURAL LANGUAGE plpgsql;

Sous PostgreSQL v9.0+ le langage plpsql est installé par le super-utilisateur, à modèle initial, qui est ensuite disponible pour le schéma nouvellement créé.

Je ne peux pas exécuter des tests sur ce projet sans résoudre cela, et même éditer ./db/development_schema.sql est manuellement futile car il est régénéré à chaque fois que je lance rake db:test:clone_structure (et ignoré par rake db:test:clone).

J'espère que quelqu'un peut faire la lumière sur ce sujet?

Note: Je l'ai utilisé à la fois la pierre précieuse adaptateur pg 0.9.0 et la pierre précieuse postgres à la version 0.7.9.2008.01.28 - à la fois afficher un comportement identique. Mes coéquipiers exécutent PostgreSQL v8.4 où l'installation de la langue est une étape manuelle.

+1

J'ai considéré que je devais supprimer le langage 'pl/pgsql', et l'installer manuellement à chaque fois. –

Répondre

8

La solution est la suivante:

Sur mon installation, il existe des modèles standards template0 et template1 - au moins si je comprends bien Postgres chercher le templateN numéro le plus élevé lors de la création d'une nouvelle base de données, à moins que le modèle est spécifié.

Dans ce cas, comme template0 inclus plpgsql, a ainsi fait template1 ... l'idée étant que vous personnaliserez template1 à la suite de votre site besoins par défaut spécifiques, et dans le cas où vous soufflez le tout, vous restaurer template1 de template0.

Comme mon site exigence spécifique était d'installer plpgsql dans le cadre de la construction automatique de mon application Web (une étape que nous devions continuer à maintenir 8,4 compatibilité) - la solution est simple: retirer plpgsql de template1 et l'avertissement/erreur parti.

Dans le cas où les paramètres par défaut spécifiques au site changeraient, et nous aurions besoin de revenir au comportement par défaut, nous simplement supprimer template1 et recréer (qui utiliserait template0)

+0

Il ne prend pas le modèle numéroté le plus élevé, il prend 'template1' sauf si vous spécifiez quelque chose d'autre. –

+0

Merci pour la clarification Peter, erreur de ma part. Dans le cas où vous supprimeriez 'template1',' template0' ne serait pas la valeur par défaut? (soutenant ainsi mon hypothèse) –

22

J'ai eu le même problème.Je fixe mon modèle avec les commandes ci-dessous

psql template1 
template1=# alter role my_user_name with superuser; 

lire plus au http://gilesbowkett.blogspot.com/2011/07/error-must-be-owner-of-language-plpgsql.html

+2

Cela fonctionne pour moi; mais qu'est-ce que 'alter role my_user_name avec le superutilisateur; –

+0

Il fait votre nom d'utilisateur my_user, SuperUser de postgres. –

+0

Ce n'est pas une bonne solution. Je ne veux pas donner à cet utilisateur des droits de superutilisateur. –

20

Pour les nouveaux lecteurs, je l'ai lu ce post plus après avoir exécuter cette erreur dans un de mes propres projets. Je pense fortement que donner à PostgreSQL un rôle de superutilisateur est une idée terrible et changer le modèle n'est pas idéal non plus. Comme les commandes PSQL référencées ajoutées par db:structure:dump ne sont pas nécessaires à la base de données de l'application Rails, j'ai écrit une tâche de rake personnalisée qui met en commentaire les lignes problématiques dans structure.sql. J'ai partagé ce code publiquement sur Github comme un Gist au https://gist.github.com/rietta/7898366.

+1

Vos commentaires sont sur place - et le fichier râteau fourni dans l'essentiel fonctionne une pêche - Merci! – Ivar

+0

Je suis d'accord, cela devrait vraiment être la réponse préférée à cette question. –

0

Je ne filtrer que les instructions d'extension plpgsql de la post-fichier de vidage structure.sql:

# lib/tasks/db.rake 

namespace :db do 
    desc "Fix 'ERROR: must be owner of extension plpgsql' complaints from Postgresql" 
    task :fix_psql_dump do |task| 
    filename = ENV['DB_STRUCTURE'] || File.join(ActiveRecord::Tasks::DatabaseTasks.db_dir, "structure.sql") 
    sql = File.read(filename) 
    sql.sub!(/(CREATE EXTENSION IF NOT EXISTS plpgsql)/, '-- \1') 
    sql.sub!(/(COMMENT ON EXTENSION plpgsql)/, '-- \1') 
    File.open(filename, 'w') do |f| 
     f.write(sql) 
    end 
    task.reenable 
    end 
end 

Rake::Task["db:structure:dump"].enhance do 
    Rake::Task["db:fix_psql_dump"].invoke 
end 
1

j'ai rencontré cette erreur en essayant de faire RAILS_ENV=development bundle exec rake db:reset. J'ai été en mesure d'accomplir la même chose (à mes fins) en faisant RAILS_ENV=development bundle exec rake db:drop db:create db:migrate à la place.