由於hstore導致表pg_restore失敗

Question

背景 ：

我在Ubuntu 14.04上使用PostgreSQL 9.3.5。

錯誤的腳本之后，我有一個表，我需要從通過pg_dump創建的轉儲文件中還原該表。 在此表上，我有一個基於此Wiki頁面的審核觸發器。 如您所見，觸發函數使用了一個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中的錯誤。 根據我上面的Per Richard Huxton的建議，我恢復了檔案。

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;

使用\\i從psql內部運行此行仍然失敗，但是可以編輯最后一行以包含公共模式（hstore的安裝位置）。

SET search_path = myschema, pg_catalog, public;

然后，我可以使用\\i從psql內部運行並導入丟失的數據。

Answer 2

我在兩個函數（ checksum和和is_valid ）以及在公共定義的表（ master_values ）中遇到了相同的問題。 在這里， checksum調用了is_valid而master_values具有一個校驗約束：

"master_values_master_id_check" CHECK(is_valid(master_id))"

注意，在任何這些中都沒有使用search_path或schema-reference。

嘗試還原轉儲時，在還原過程中得到了以下信息：

pg_restore: [archiver (db)] COPY failed for table "master_values": ERROR:  function checksum(integer) does not exist

奇怪的是，還原后，函數和表都已存在並且可以按預期工作。 唯一缺少的是在數據master_values未得到恢復。

通過為is_valid指定search_path解決此問題：

ALTER FUNCTION is_valid SET search_path = public;

有關此的更多信息，請參見：

• docs： https : //www.postgresql.org/docs/current/sql-alterfunction.html
• Article1： https ： //www.postgresonline.com/article_pfriendly/279.html
• 第2條： https ： //www.endpoint.com/blog/2012/11/15/postgresql-searchpath-behaviour