On Wed Jul 23, 2025 at 7:12 PM CEST, Artem Gavrilov wrote:
Hello Jelte,
1) I noticed that pg_dump changes weren't covered with tests.
2) I assume these error messages may be confusing, especially first one:
Attached is an updated version that addresses these issues.
From 7cc55c4e3a1fe2b5d958a
On Mon, 28 Jul 2025 at 00:03, Sadeq Dousti wrote:
> (a) The patch affects DROP EXTENSION in that it drops the schema as well, if
> it's owned by the extension. This needs to be mentioned in the documentation.
> In addition, an extra confirmation (e.g., "This will drop schema as
> well, do
You're absolutely right about the lack of interactivity. I'd still go with
your suggestion of using something along the lines of cascade/force, as
dropping the schema silently can potentially delete the user data.
Bests,
Sadeq
On Mon, Jul 28, 2025, 02:27 David G. Johnston
wrote:
> On Sunday, Ju
On Sunday, July 27, 2025, Sadeq Dousti wrote:
>
> (a) The patch affects DROP EXTENSION in that it drops the schema as well,
> if it's owned by the extension. This needs to be mentioned in the
> documentation. In addition, an extra confirmation (e.g., "This will drop
> schema as well, do you
Dear Jelte,
I like the idea! In fact, I was thinking about the general search_path
confusion issue in Postgres (see also [1]), and what the root cause is.
IMHO, some search paths should always take priority - e.g., if a function
is defined in both pg_catalog and as a UDF, the UDF should only be ca
Hello Jelte,
I reviewed your patch. Overall it looks good, I didn't find any problems
with code. Documentation is in place and clear.
Initial Run
===
The patch applies cleanly to HEAD (196063d6761). All tests successfully
pass.
Comments
===
1) I noticed that pg_dump changes weren
On Fri, 27 Sept 2024 at 14:00, Tomas Vondra wrote:
> One thing that's not quite clear to me is what's the correct way for
> existing extensions to switch to an "owned schema". Let's say you have
> an extension. How do you transition to this? Can you just add it to the
> control file and then some
Hi,
I've spent a bit of time looking at this patch. It seems there's a clear
consensus that having "owned schemas" for extensions would be good for
security. To me it also seems as a convenient way to organize stuff. It
was possible to create extensions in a separate schema before, ofc, but
that's
On Jun 19, 2024, at 13:50, Jelte Fennema-Nio wrote:
> This indeed does sound like the behaviour that pretty much every
> existing extension wants to have. One small addition/clarification
> that I would make to your definition: fully qualified references to
> other objects should still be allowed
On Jun 19, 2024, at 11:28, Robert Haas wrote:
> But I wonder if there might also be another possible approach: could
> we, somehow, prevent object references in extension scripts from
> resolving to anything other than the system catalogs and the contents
> of that extension? Perhaps with a contr
On Wed, Jun 19, 2024 at 1:50 PM Jelte Fennema-Nio wrote:
> I do think, even if we have this, there would be other good reasons to
> use "owned schemas" for extension authors. At least the following two:
> 1. To have a safe search_path that can be used in SET search_path on a
> function (see also [
On Wed, 19 Jun 2024 at 17:22, David G. Johnston
wrote:
>
> On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote:
>
>>
>> Because part of it would
>> only be relevant once we support upgrading from PG18. So for now the
>> upgrade_code I haven't actually run.
>
>
> Does it apply against v16? If
On Wed, 19 Jun 2024 at 19:55, Tom Lane wrote:
>
> Jelte Fennema-Nio writes:
> > On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
> >> I have a feeling that this might be pretty annoying to implement, and
> >> if that is true, then never mind.
>
> > Based on a quick look it's not trivial, but als
Jelte Fennema-Nio writes:
> On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
>> I have a feeling that this might be pretty annoying to implement, and
>> if that is true, then never mind.
> Based on a quick look it's not trivial, but also not super bad.
> Basically it seems like in src/backend/ca
On Wed, 19 Jun 2024 at 17:28, Robert Haas wrote:
> But I wonder if there might also be another possible approach: could
> we, somehow, prevent object references in extension scripts from
> resolving to anything other than the system catalogs and the contents
> of that extension?
This indeed does
On Sat, Jun 1, 2024 at 8:08 PM Jelte Fennema-Nio wrote:
> Writing the sql migration scripts that are run by CREATE EXTENSION and
> ALTER EXTENSION UPDATE are security minefields for extension authors.
> One big reason for this is that search_path is set to the schema of the
> extension while runni
On Wed, Jun 19, 2024 at 8:19 AM Jelte Fennema-Nio wrote:
> Because part of it would
> only be relevant once we support upgrading from PG18. So for now the
> upgrade_code I haven't actually run.
>
Does it apply against v16? If so, branch off there, apply it, then upgrade
from the v16 branch to
Attached is an updated version of this patch that fixes a few issues
that CI reported (autoconf, compiler warnings and broken docs).
I also think I changed the pg_upgrade to do the correct thing, but I'm
not sure how to test this (even manually). Because part of it would
only be relevant once we s
On Wed, 5 Jun 2024 at 19:53, Jeff Davis wrote:
> Is this orthogonal to relocatability?
It's fairly orthogonal, but it has some impact on relocatability: You
can only relocate to a schema name that does not exist yet (while
currently you can only relocate to a schema that already exists). This
is
On Sat, 2024-06-01 at 17:08 -0700, Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed. What that means is that the
> schema should not exist
On Sun, Jun 2, 2024, 02:08 Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed.
Huge +1
Many managed PostgreSQL services block superuser a
Writing the sql migration scripts that are run by CREATE EXTENSION and
ALTER EXTENSION UPDATE are security minefields for extension authors.
One big reason for this is that search_path is set to the schema of the
extension while running these scripts, and thus if a user with lower
privileges can cr
22 matches
Mail list logo
