From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: AKASH <akashbhujbal7051@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Evidence of Ownership Issues During Restoration of Extension Member Objects
Date: Tue, 28 Jan 2025 01:33:50 -0500
Message-ID: <1066373.1738046030@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKFQuwYMWQRdhj0SPiW0KnmwMOi0pEmdyWKeyOxDa+GSb5U6VA@mail.gmail.com>
References: <CABaoBc6UyWJ=v4NgmC15SkBtBq_g0GBRgZPrdks2q6=ke0-4Mg@mail.gmail.com>
<CABaoBc4QzQHBFKGvAa99BpcfyAgjqH_JKrSox9P62dkhfOpDdw@mail.gmail.com>
<CAKFQuwYMWQRdhj0SPiW0KnmwMOi0pEmdyWKeyOxDa+GSb5U6VA@mail.gmail.com>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> As an aside, none of the use cases are framed to directly motivate why you
> would take the actions described, so we are still just left seeing
> unnecessary attempts to make unsupported changes to the system permissions
> setup and responding with “don’t do that”.
The short answer here is that dump/restore is not intended to
reproduce any manual changes you might've made to the contents
of an extension --- with the sole exception, since around v9.6,
that it will try to reproduce permissions changes (NOT ownership
changes) for objects contained in the extension. TBH, I think
that part was a misfeature we shouldn't have accepted, because
it breaks the abstraction that an extension is a black box whose
contents are described by on-disk script files.
The use-case driving that definition is that dump/restore
will install whatever version of the extension is considered
current on the target system, which might well be different
from what the source system had (which indeed might not be
available on the target). So the more the dump script
assumes about what is in the extension, the more likely it
is to fail.
You might want to look into pg_upgrade, which has a different
charter: it tries to reproduce the extension contents exactly.
Anyway, we are not going to accept the described scenario
as a bug. As I already said, manual alteration of the contents
of an extension is unsupported --- and *in particular* that
means we will not promise that dump/restore does anything
useful with such cases.
There are certainly things I don't like about what dump/restore
does with extension object ownership: it doesn't really attempt
at all to duplicate the extension's original ownership. But
anything we might do to fix that would make it even less likely
that manual alteration of individual member objects' ownership
would be preserved.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, akashbhujbal7051@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Evidence of Ownership Issues During Restoration of Extension Member Objects
In-Reply-To: <1066373.1738046030@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox