| 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:24:13 |
| Message-ID: | CAKFQuwa-2kBY_RnvLXE+XqdmuPtadN-B5XEmT7fdbw9_9+BfHA@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:
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-07-08 20:24:28 | Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works |
| Previous Message | David G. Johnston | 2021-07-08 20:19:11 | Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works |