From 356d850cd390724072ec67c7f6848872bb0f1c7e Mon Sep 17 00:00:00 2001 From: "Karl O. Pinc kop@karlpinc.com" Date: Fri, 14 Feb 2025 18:16:26 +0000 Subject: [PATCH] Work around what looks like an m4 bug preventing macro expansion Seems like macros used on the first line of footnotes don't expand. --- doc/src/architecture/logins.m4 | 3 ++- doc/src/architecture/permissions.m4 | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/src/architecture/logins.m4 b/doc/src/architecture/logins.m4 index 7ec749a..48c72b0 100644 --- a/doc/src/architecture/logins.m4 +++ b/doc/src/architecture/logins.m4 @@ -133,7 +133,8 @@ interacting with database content. or extension installation, and thus, like administrators, have access to the server's file system and server executables. -.. [#f3] Developers are not in the ``sdb_role_owner`` group. +.. [#f3] Developers + are not in the ``sdb_role_owner`` group. .. [#f4] The Azure cloud platform does not allow logins (aka roles) to have the ``SUPERUSER`` `role attribute`. diff --git a/doc/src/architecture/permissions.m4 b/doc/src/architecture/permissions.m4 index 64aeea8..a300f1d 100644 --- a/doc/src/architecture/permissions.m4 +++ b/doc/src/architecture/permissions.m4 @@ -88,7 +88,8 @@ This will give all administrators the requisite additional access. .. [#f2] SQL is ordinarily only used to change a login's permission level. -.. [#f3] The ``sdb_role_owner`` group exists only because roles do not +.. [#f3] The + ``sdb_role_owner`` group exists only because roles do not have ``WITH ADMIN TRUE`` on themselves. So the ``sdb_admin_group`` role cannot grant the ability to become itself to administrators, who need to be able to -- 2.34.1