From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | wilma(dot)wantren(at)web(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18249: pg_dump/pg_restore single schema with function1 calling function2 |
Date: | 2023-12-15 13:03:43 |
Message-ID: | a5b6415b5d1f45e79600b8ad4d369fecd9c9f8d2.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 2023-12-15 at 09:09 +0000, PG Bug reporting form wrote:
> [...] pg_dump/pg_restore [...]
>
> But there is one problem: we have a database function function1, which calls
> another function function2. The call is made without a schema prefix because
> these are just two functions that we make available to the customers and we
> don't think an extra schema for these two functions is worthwhile. However,
> function1 is used in an index and the restore of the index fails if there is
> data in the corresponding table column. This is because pg_dump/pg_restore
> set the search_path to '' when restoring, which means that function1 cannot
> find the function2.
> Is there any way to solve this?
This is a bug, but not a PostgreSQL bug. The bug is in your object definition.
Relying on "search_path" like that is a security risk, particularly in
functions used in an index definition. If a privileged user inserts a value
in an environment where somebody else can manipulate "search_path", anything
can happen.
The best fix is to
ALTER FUNCTION ... SET search_path = only, safe, schemas;
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Wetmore, Matthew (CTR) | 2023-12-15 14:29:38 | BUG #18249: pg_dump/pg_restore single schema with function1 calling function2 |
Previous Message | Alexander Lakhin | 2023-12-15 13:00:01 | Re: BUG #18246: pgstathashindex() attempts to read invalid file for hash index attached to partitioned table |