Обсуждение: pg_restore: [archiver (db)] could not execute query: ERROR: operatordoes not exist: public.hstore = public.hstore
I am exporting DB from 10.6 and importing into 10.7 and an UPDATE rule fails to restore. I have a view and a rule that starts like this
CREATE OR REPLACE RULE table_view__upd__rul AS ON UPDATE
TO cfg.table_view
DO INSTEAD (
UPDATE sch.tab
SET
updated_at = NEW.updated_at,
updated_by = NEW.updated_by,
hstore_field = NEW.hstore_field
WHERE id = OLD.id
AND
(
OLD.updated_at IS DISTINCT FROM NEW.updated_at OR
OLD.updated_by IS DISTINCT FROM NEW.updated_by OR
OLD.hstore_field IS DISTINCT FROM NEW.hstore_field
);
....
I export into a custom format as
pg_dump -F c -Z 0 -T bak.* -T tmp.* -h host -p port database > file.dump
and import with
pg_restore -v -d database -j 4 -p port file.dump
which results into an error
pg_restore: [archiver (db)] could not execute query: ERROR: operator does not exist: public.hstore = public.hstore
LINE 3: ...ISTINCT FROM (new.updated_by)::text) OR (old.hstore_field IS DISTINC...
with an arrow pointing to "old.hstore_field IS -->DISTINC..."
From the log I can see that hstore was extension successfully created and many other tables, views and functions successfully recreated prior to this error.
This looks like a bug to me :(
Thank you!
Cherio <cherio@gmail.com> writes: > I am exporting DB from 10.6 and importing into 10.7 and an UPDATE rule > fails to restore: > pg_restore: [archiver (db)] could not execute query: ERROR: operator does > not exist: public.hstore = public.hstore > From the log I can see that hstore was extension successfully created It's probably not in the search_path that pg_restore was using. This is one of the hard-to-fix consequences of the decision to band-aid over CVE-2018-1058 by having pg_restore run with a minimal search_path. pg_dump can't forestall the problem by schema-qualifying the operator name, because there is no explicit operator name in IS DISTINCT FROM. I complained at the time that there needed to be a way to relax the restriction, but I lost the argument. AFAIK the only workaround that exists at the moment is to hand-edit the dump script to change the forced search_path setting to include whereever you put hstore (and any other extensions you have similar issues with). There's a previous discussion here: https://www.postgresql.org/message-id/flat/ffefc172-a487-aa87-a0e7-472bf29735c8%40gmail.com but it seems like nobody's done any work on it since then. regards, tom lane