pg_restore on table failing because of hstore - postgresql

Question

Background:
I'm using PostgreSQL 9.3.5 on Ubuntu 14.04.
After a bad script, I have a table that I need to restore from a dump file created via pg_dump. On this table, I have an audit trigger that is based on
this wiki page. As you can see, the trigger function uses an hstore.
Error:
When I attempt the restore, I get:
$ 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;
The extension definitely does exist.
=> \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)
And I can use it in a query (as the postgres user - the same role as I'm using above for the restore):
=> 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)
Questions:
Why am I getting this error when the database has this extension installed?
Other than dropping the trigger, how can I get around this issue? Dropping trigger is not the worse thing in the world, but it seems like this should be possible and in a production database, I'd like to be able to see the audit trail that someone did a restore of the data, etc.

Answer 1

It appears to be a bug in either pg_dump or pg_restore. Per Richard Huxton's suggestion above I restored to a file.
pg_restore --data-only --table=foo -f ~/tmp/foo.sql ~/tmp/a193.dump
When I looked at the contents, I found that it was doing the following at the top:
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;
Running this line from inside of psql with \i still fails, but editing the last line to include the public schema (which is where hstore is installed) works.
SET search_path = myschema, pg_catalog, public;
I'm then able to run from inside psql with \i and import the lost data.

Answer 2

I had the same issue with two functions (checksum and is_valid) and a table (master_values) defined in public. Here checksum was calling is_valid and master_values had a check-constraint:
"master_values_master_id_check" CHECK(is_valid(master_id))"
Note that there was no search_path or schema-reference used in any of these.
When trying to restore the dump I got this during the restore:
pg_restore: [archiver (db)] COPY failed for table "master_values": ERROR: function checksum(integer) does not exist
The strange thing is that after the restore both functions and the table are there and works as expected. The only thing missing is the data in master_values that did not get restored.
This was solved by specifying the search_path for is_valid:
ALTER FUNCTION is_valid SET search_path = public;
For more info on this see:
The docs: https://www.postgresql.org/docs/current/sql-alterfunction.html
Article1: https://www.postgresonline.com/article_pfriendly/279.html
Article2: https://www.endpoint.com/blog/2012/11/15/postgresql-searchpath-behaviour