From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump dump catalog ACLs |
Date: | 2016-03-01 04:52:37 |
Message-ID: | 14969.1456807957@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> No, the point of it would be to not have pg_dump scripts overriding
>> installed-by-default ACLs. A newer PG version might have different
>> ideas about what those should be. I don't think this is exactly an
>> academic concern, either: wouldn't a likely outcome of your default-roles
>> work be that some built-in functions have different initial ACLs than
>> they do today? Good luck with that, if pg_upgrade overwrites those
>> ACLs with the previous-version values.
> As it turns out, there isn't such an issue as the default for functions
> is to allow PUBLIC to EXECUTE and therefore we don't dump out ACLs for
> most functions. The follow-on change to this patch is to modify those
> functions to *not* have the default/NULL ACL (and also drop the explicit
> if (!superuser()) ereport() checks in those functions), which will work
> just fine and won't be overwritten during pg_upgrade because those
> functions currently just have the default ACL, which we don't dump out.
Yes, so it would probably manage to not fail during 9.6 -> 9.7 migration.
But you *won't ever again* get to change the default ACLs on those
functions. That does not seem like a great bet from here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rushabh Lathia | 2016-03-01 05:34:14 | Logic problem in SerializeSnapshot() |
Previous Message | Dilip Kumar | 2016-03-01 04:49:56 | Re: Move PinBuffer and UnpinBuffer to atomics |