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 CAKFQuwa-2kBY_RnvLXE+XqdmuPtadN-B5XEmT7fdbw9_9+BfHA@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:
This isn't the only SQL syntax that has implicit operators; CASE is
another example, and I think there are more.  We've discussed inventing
non-SQL-spec syntax that can cope with explicitly writing a qualified
operator name in all these cases, but it looks like a messy project
with an ugly final result :-(, so nothing's been done yet.


IIUC, functions can force a search_path even during dump/restore by being created with one specified as part of the create function command.  Since the issue is with stored objects moreso than queries generically is it feasible to approach the view solution by adding a "SET" clause to CREATE VIEW as well?
David J.

pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Next
From: Tom Lane
Date:
Subject: Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works