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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Causer <chy(dot)causer(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Date: 2021-07-08 20:19:11
Message-ID: CAKFQuwaKcK8Wg++sNdMJ3jR58Lfas-98xk2a3am=fXasGs0ADg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jul 8, 2021 at 1:09 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2021-07-08 20:24:13 Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Previous Message Ron 2021-07-08 20:09:56 Re: On partitioning, PKs and FKs