Re: pg_dump needs SELECT privileges on irrelevant extension table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump needs SELECT privileges on irrelevant extension table
Date
Msg-id 3152156.1697660739@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump needs SELECT privileges on irrelevant extension table  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_dump needs SELECT privileges on irrelevant extension table
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Greetings,
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I wrote:
>>> Why are we marking extension member objects as being subject to SECLABEL
>>> or POLICY dumping?

> This change would mean that policies added by a user after the extension
> is created would just be lost by a pg_dump/reload, doesn't it?

Yes.  But I'd say that's unsupported, just like making other ad-hoc
changes to extension objects is unsupported (and the effects will be
lost on dump/reload).  We specifically have support for user-added
ACLs, and that's good, but don't claim that we have support for
doing the same with policies.

As far as I can see, the current behavior is that we'll dump and
try to reload policies (and seclabels) on extension objects even
if those properties were set by the extension creation script.
That has many more problems than just the one Jacob is moaning
about: you'll see failures at reload if you're not superuser,
and if the destination installation has a newer version of the
extension than what was dumped, the old properties might be
completely inappropriate.  So IMO there's basically nothing
that works properly about this.  To make it work, we'd need
infrastructure comparable to the pg_init_privs infrastructure.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_dump needs SELECT privileges on irrelevant extension table
Next
From: Tom Lane
Date:
Subject: Re: Add support for AT LOCAL