| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: functional index search path issue. |
| Date: | 2025-07-05 14:53:13 |
| Message-ID: | CAKFQuwYD1XW-DTg=OSh9CMazX+B9XMLRQx3+5eWyUKsqx1gJQQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Saturday, July 5, 2025, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> Is this a postgres fault? One thing is with pg_upgrade failing for a
> valid database, but maybe users should just re-create their indices
> with fully-qualified names.
>
Yes, functions you intend for the server to execute during dump/restore or
other administrative routines where it sets up a safe searh_path need to be
able to resolve all identifiers without the benefit of a session-defined
search_path beyond pg_catalog. Public is not part of the safe search_path.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2025-07-05 15:07:38 | Re: Unexpected behavior when setting "idle_replication_slot_timeout" |
| Previous Message | Fujii Masao | 2025-07-05 14:44:05 | Re: Unexpected behavior when setting "idle_replication_slot_timeout" |