pg_restore на столе неудачу из-за hstore

Question

фон:

Я использую PostgreSQL 9.3.5 на Ubuntu 14.04.

После неудачного сценария у меня есть таблица, которую мне нужно восстановить из файла дампа, созданного через pg_dump. В этой таблице у меня есть триггер аудита, основанный на . wiki page. Как вы можете видеть, функция триггера использует hstore.

Ошибка:

При попытке восстановления, я получаю:

$ pg_restore -a --dbname=a193 -Fc --host=localhost --port=5434 --username=postgres -W --table=foo ~/tmp/a193.dump 
Password: 
pg_restore: [archiver (db)] Error while PROCESSING TOC: 
pg_restore: [archiver (db)] Error from TOC entry 4600; 0 26146 TABLE DATA foo u2su8s81ul0a52 
pg_restore: [archiver (db)] COPY failed for table "foo": ERROR: type "hstore" does not exist 
LINE 6:  h_old hstore; 

Расширение определенно существует.

=> \dx 
             List of installed extensions 
+--------------------+---------+------------+--------------------------------------------------------------+ 
|  Name  | Version | Schema |       Description       | 
+--------------------+---------+------------+--------------------------------------------------------------+ 
| dblink    | 1.1  | public  | connect to other PostgreSQL databases from within a database | 
| hstore    | 1.2  | public  | data type for storing sets of (key, value) pairs    | 
| isn    | 1.0  | public  | data types for international product numbering standards  | 
| pg_stat_statements | 1.1  | public  | track execution statistics of all SQL statements executed | 
| pgcrypto   | 1.0  | public  | cryptographic functions          | 
| plpgsql   | 1.0  | pg_catalog | PL/pgSQL procedural language         | 
| plpythonu   | 1.0  | pg_catalog | PL/PythonU untrusted procedural language      | 
| postgres_fdw  | 1.0  | public  | foreign-data wrapper for remote PostgreSQL servers   | 
| uuid-ossp   | 1.0  | public  | generate universally unique identifiers (UUIDs)    | 
+--------------------+---------+------------+--------------------------------------------------------------+ 
(9 rows) 

И я могу использовать его в запросе (как пользователь Postgres - ту же роль, как я использую выше для восстановления):

=> select current_user; 
+--------------+ 
| current_user | 
+--------------+ 
| postgres  | 
+--------------+ 
(1 row) 

=> \du 
           List of roles 
+----------------+------------------------------------------------+-----------+ 
| Role name |     Attributes     | Member of | 
+----------------+------------------------------------------------+-----------+ 
| postgres  | Superuser, Create role, Create DB, Replication | {}  | 
| u2su8s81ul0a52 |            | {}  | 
+----------------+------------------------------------------------+-----------+ 

=> select 'a=>1'::hstore; 
+----------+ 
| hstore | 
+----------+ 
| "a"=>"1" | 
+----------+ 
(1 row) 

Вопросы:

1. Почему я получаю эту ошибку, когда база данных имеет это расширение?
2. За исключением того, что вы бросаете курок, как я могу обойти эту проблему? Сбрасывание триггеров не хуже в мире, но похоже, что это должно быть возможно, и в производственной базе данных я бы хотел увидеть контрольный след, что кто-то восстановил данные и т. Д.

Answer 1

Это, кажется, ошибка в pg_dump или pg_restore. По предложению Ричарда Хукстона выше я вернулся к файлу.

pg_restore --data-only --table=foo -f ~/tmp/foo.sql ~/tmp/a193.dump 

Когда я посмотрел на содержимое, я обнаружил, что он делал следующее: в верхней части

SET statement_timeout = 0; 
SET client_encoding = 'UTF8'; 
SET standard_conforming_strings = on; 
SET check_function_bodies = false; 
SET client_min_messages = warning; 
SET search_path = myschema, pg_catalog; 

Запуск этой линии изнутри PSQL с \i до сих пор не удается, но редактирование последней строки включить общедоступную схему (в которой установлен hstore).

SET search_path = myschema, pg_catalog, public; 

Я тогда в состоянии работать с внутренней PSQL с \i и импортировать потерянные данные.