On 2026-Feb-19, Tom Lane wrote:
> After sleeping on it, I decided that much of the cognitive dissonance
> here comes from the fact that elsewhere in the catalog data files
> we represent the bootstrap user's name as POSTGRES, making it more
> obvious that that's a placeholder and not the real value. If we do
> that here and also drop the redundant grantor specifications, we get
>
> + proacl => '{POSTGRES=X,pg_read_all_stats=X}' },
>
> which is still not the world's prettiest notation, but it feels
> manageable for this purpose.
Yeah, I like this better, for exactly that reason -- looking at the
previous one I was worried that my setup would no longer work or behave
differently, because my PG superusers are all called something not
"postgres", and on first sight these ACL lines seemed like they wouldn't
work properly.
I tested this patch here and it seems to behave as intended. I like the
tightening of ::1 processing as well, though maybe that should be its
own preliminary commit, to make it clear that it isn't in fact changing
anything.
The deal with system_views.sql is not clear to me. Previously, the
function underlying each view was in pg_proc.dat and the ACL was tweaked
in system_views.sql together with the place where the function was used
to define the view; now it seems the whole of the function (incl its
ACL) is in pg_proc.dat, and only the view itself is in system_views.sql.
I think this is an OK arrangement, but perhaps there should be a comment
in system_views.sql about it.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)
