Re: pg_dump dump catalog ACLs
От | Tom Lane |
---|---|
Тема | Re: pg_dump dump catalog ACLs |
Дата | |
Msg-id | 14969.1456807957@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump dump catalog ACLs (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_dump dump catalog ACLs
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: