Re: Add more sanity checks around callers of changeDependencyFor()
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-06T17:09:20Z
Lists: pgsql-hackers
Hi, On 2023-07-05 14:10:42 +0900, Michael Paquier wrote: > On Tue, Jul 04, 2023 at 02:40:04PM -0400, Tom Lane wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > >> Hmm, shouldn't we disallow moving the function to another schema, if the > >> function's schema was originally determined at extension creation time? > >> I'm not sure we really want to allow moving objects of an extension to a > >> different schema. > > > > Why not? I do not believe that an extension's objects are required > > to all be in the same schema. > > Yes, I don't see what we would gain by putting restrictions regarding > which schema an object is located in, depending on which schema an > extension uses. Well, it adds an exploitation opportunity. If other functions in the extension reference the original location (explicitly or via search_path), somebody else can create a function there, which might be called from a more privileged context. Obviously permissions limit the likelihood of this being a real issue. I also don't think pg_dump will dump the changed schema, which means a dump/restore leads to a different schema - IMO something to avoid. Greetings, Andres Freund
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add more sanity checks with callers of changeDependencyFor()
- 9b286858e3ab 17.0 landed
-
Fix ALTER EXTENSION SET SCHEMA with objects outside an extension's schema
- 914e72e6e8d3 11.21 landed
- 02021f1b2f65 12.16 landed
- f5b075adcf4c 13.12 landed
- 235e716bc24d 14.9 landed
- d1e0f408cbe2 15.4 landed
- 55c95f24cd7c 16.0 landed
- bd5ddbe8666a 17.0 landed