pg_dump 的恢复给出“运算符不存在：public.iprange = public.iprange

Question

我有一个相当大的架构。由于最近对某些函数和视图进行了调整，我无法通过 psql 或 pg_restore.

恢复它

~$ psql  -f schema.sql foo -v ON_ERROR_STOP=1                                                                                                                                                                         
....[SNIP]
psql:schema.sql:2405: ERROR:  operator does not exist: public.iprange = public.iprange

为了完整起见，失败的观点如下。在从中获取转储的现有生产数据库上，它工作正常：


CREATE VIEW archive.subnet_dhcp_options AS
 SELECT sdo.id,
    sdo.subnet_range,
    (sdo.subnet_pools)::text[] AS subnet_pools,
    sdo.dhcp_options,
    sdo.unknown_client_leases,
    sdo.kea_subnet_id,
    public.family(sdo.subnet_range) AS ip_version,
    sdo.comment,
    sdo.created_in_transaction,
    sdo.deleted_in_transaction,
    array_to_string((sdo.subnet_pools)::text[], '
'::text) AS subnet_pools_as_string,
    public.subnet_dhcp_option_last_update(sdo.subnet_range) AS last_update,
    s.id AS subnet_id
   FROM (data.subnet_dhcp_options sdo
     JOIN public.subnets s USING (subnet_range));

但我知道这个运算符确实存在。真的奇怪的是，我可以在数据库停止的地方获取数据库，然后毫无问题地复制粘贴视图：视图是在恢复停止的地方创建的。

我也可以这样编辑视图然后重新运行 psql -f schema.sql:

CREATE VIEW archive.subnet_dhcp_options AS
 SELECT -- SAME_COLUMNS_AS_ABOVE
   
   FROM (data.subnet_dhcp_options sdo
     JOIN public.subnets s ON (s.subnet_range::text = sdo.subnet_range::text));

基本上我已经将 iprange= 运算符更改为文本运算符，这对我们来说不是一个可行的解决方案。

我试过恢复到 9.6 和 13。两者都有同样的错误。该架构使用 ossp-uuid 和 ip4r 扩展。

如有任何帮助，我们将不胜感激。我从来没有遇到过数据库无法从 pg_dump 恢复的情况，对此我真的很抓狂。

pg_dump 已经运行没有参数但有 --schema-only。两者都表现出这种行为。

编辑：

澄清一下

ip4r 已安装并且运行ning 正常。事实上，我正在将数据库恢复到同一个系统和同一个集群，只是数据库名称不同。
不幸的是，架构的更改非常大，因为它是一个大的新版本。该软件的工作方式是数据库内部有许多视图和函数，看起来它在其中一个视图上绊倒了，即使我可以将其复制并粘贴到完成一半的恢复中。
可能是上一点的重复，但 ip4r 安装在 public 架构中。事实上，这一定是因为这个视图所基于的表（而不是视图）创建得很好。
subnet_range 是两个表的 iprange 类型，尽管其中一个表本身就是一个视图

虽然我觉得架构太冗长无法在 SO 上分享，但这不是商业秘密。如果有人知道与感兴趣的人分享它的方法，我很乐意这样做。

编辑 2:

不幸的是，迁移是以编程方式生成的，因此虽然可以提取差异，但它会相当大且难以拆解。但是，这可能更好，我已经设法将架构压缩到给出错误的最小值。当您运行通过 psql -f - 时，您会在最后一次查看时收到上述错误。然后您可以启动一个 psql 终端并粘贴到最终的 VIEW 中，它工作正常。

这是数据库的 pg_dump，我只删除了与错误无关的行和注释。我没有添加任何行。

希望这足以说明我遇到的问题

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

CREATE SCHEMA archive;
CREATE SCHEMA auth;
CREATE SCHEMA data;
CREATE SCHEMA minion;
CREATE SCHEMA user_views;


CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
CREATE EXTENSION IF NOT EXISTS ip4r WITH SCHEMA public;
CREATE EXTENSION IF NOT EXISTS pgcrypto WITH SCHEMA public;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp" WITH SCHEMA public;


CREATE TABLE data.subnet_dhcp_options_updates_log (
    subnet_range public.iprange NOT NULL,
    txid bigint NOT NULL,
    last_update timestamp without time zone NOT NULL
);

CREATE FUNCTION public.subnet_dhcp_option_last_update(arg_subnet_range public.iprange) RETURNS timestamp without time zone
    LANGUAGE sql STABLE
    AS $$
  select last_update from data.subnet_dhcp_options_updates_log where subnet_range = arg_subnet_range;
$$;


CREATE TABLE data.subnets (
    id uuid DEFAULT public.uuid_generate_v4() NOT NULL,
    subnet_range public.iprange NOT NULL,
    comment text DEFAULT ''::text NOT NULL,
    created_in_transaction bigint DEFAULT txid_current() NOT NULL,
    deleted_in_transaction bigint,
    subnet_name text DEFAULT ''::text NOT NULL,
    is_visible boolean DEFAULT true NOT NULL
);

CREATE VIEW archive.subnets AS
 SELECT subnets.id,
    subnets.subnet_range,
    subnets.comment,
    subnets.created_in_transaction,
    subnets.deleted_in_transaction,
    subnets.subnet_name,
    subnets.is_visible,
    public.family(subnets.subnet_range) AS ip_version
   FROM data.subnets;



CREATE TABLE data.subnet_dhcp_options (
    id uuid NOT NULL,
    kea_subnet_id integer NOT NULL,
    subnet_range public.iprange NOT NULL,
    subnet_pools public.iprange[] DEFAULT '{}'::public.iprange[] NOT NULL,
    dhcp_options jsonb DEFAULT '{}'::jsonb NOT NULL,
    unknown_client_leases boolean NOT NULL,
    comment text DEFAULT ''::text NOT NULL,
    created_in_transaction bigint DEFAULT txid_current() NOT NULL,
    deleted_in_transaction bigint
);



CREATE VIEW public.subnets AS
 SELECT subnets.id,
    subnets.subnet_range,
    subnets.comment,
    subnets.created_in_transaction,
    subnets.deleted_in_transaction,
    subnets.subnet_name,
    subnets.is_visible,
    subnets.ip_version
   FROM archive.subnets
  WHERE (subnets.deleted_in_transaction IS NULL);


CREATE VIEW archive.subnet_dhcp_options AS
 SELECT sdo.id,
    sdo.subnet_range,
    (sdo.subnet_pools)::text[] AS subnet_pools,
    sdo.dhcp_options,
    sdo.unknown_client_leases,
    sdo.kea_subnet_id,
    public.family(sdo.subnet_range) AS ip_version,
    sdo.comment,
    sdo.created_in_transaction,
    sdo.deleted_in_transaction,
    array_to_string((sdo.subnet_pools)::text[], '
'::text) AS subnet_pools_as_string,
    public.subnet_dhcp_option_last_update(sdo.subnet_range) AS last_update,
    s.id AS subnet_id
   FROM (data.subnet_dhcp_options sdo
     JOIN public.subnets s USING (subnet_range));

Answer 1

我不能以此为荣。我不得不询问 PostgreSQL 通用邮件列表，但得到了非常有帮助的回复，我将尝试解释一下。

问题出在这点视图上

 JOIN ... USING (subnet_range))

这个USING和ON (s.subnet_range = sdo.subnet_range)一样，我是这么想的。事实上，= 是一个本身位于模式中的运算符。当您在终端创建视图时，隐含了“public”模式。相比之下，出于安全原因，pg_dump 明确删除了模式解析（通过 pg_catalog.set_config('search_path', '', false)）。然后它完全限定后续转储中的所有对象。不幸的是，在 USING 的情况下，它不能这样做，因为运算符是隐含的而不是明确说明的。

但是，如果我将 USING 更改为 ON，转储可以“看到”运算符并因此重写它以使其完全合格。对我的数据库模式进行更改并转储它，我现在得到了行

 JOIN public.subnets s ON ((s.subnet_range OPERATOR(public.=) sdo.subnet_range)));

现在我可以愉快地再次转储和恢复数据库了。快乐的日子。

pg_dump 的恢复给出“运算符不存在：public.iprange = public.iprange

pg_dump's restore gives "operator does not exist: public.iprange = public.iprange

postgresql

pg-dump