Postgres Pro
Downloads
Home   >   mailing lists

Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works - Mailing list pgsql-general

From David G. Johnston
Subject Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Date
Msg-id CAKFQuwaKcK8Wg++sNdMJ3jR58Lfas-98xk2a3am=fXasGs0ADg@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tree view
On Thu, Jul 8, 2021 at 1:09 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

I don't think there's any good solution right now.

For joins it is generally easy enough to resort to the ON clause instead of USING so of the various places there are problems this is probably the least.

I'll admit these have been infrequent since resolving CVE 2018-1058, but I still disagree with the decision to not give the DBA an option on whether to leave public in their search_path during a pg_dump and pg_restore.

David J.

pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: On partitioning, PKs and FKs
Next
From: "David G. Johnston"
Date:
Subject: Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works