diff --git a/doc/src/sgml/information_schema.sgml b/doc/src/sgml/information_schema.sgml
index 350c75bc31..5f661552d8 100644
--- a/doc/src/sgml/information_schema.sgml
+++ b/doc/src/sgml/information_schema.sgml
@@ -183,8 +183,8 @@
 
   <para>
    The view <literal>administrable_role_authorizations</literal>
-   identifies all roles that the current user has the admin option
-   for.
+   identifies all roles that the current user has the <literal>ADMIN</literal>
+   option for.
   </para>
 
   <table>
diff --git a/doc/src/sgml/ref/alter_group.sgml b/doc/src/sgml/ref/alter_group.sgml
index b9e641818c..4b528498df 100644
--- a/doc/src/sgml/ref/alter_group.sgml
+++ b/doc/src/sgml/ref/alter_group.sgml
@@ -55,7 +55,7 @@ ALTER GROUP <replaceable class="parameter">group_name</replaceable> RENAME TO <r
    <link linkend="sql-revoke"><command>REVOKE</command></link>. Note that
    <command>GRANT</command> and <command>REVOKE</command> have additional
    options which are not available with this command, such as the ability
-   to grant and revoke <literal>ADMIN OPTION</literal>, and the ability to
+   to grant and revoke <literal>ADMIN</literal> option, and the ability to
    specify the grantor.
   </para>
 
diff --git a/doc/src/sgml/ref/createuser.sgml b/doc/src/sgml/ref/createuser.sgml
index c6a7c603f7..22cd885c82 100644
--- a/doc/src/sgml/ref/createuser.sgml
+++ b/doc/src/sgml/ref/createuser.sgml
@@ -82,7 +82,8 @@ PostgreSQL documentation
       <listitem>
        <para>
         Indicates role that will be immediately added as a member of the new
-        role with admin option, giving it the right to grant membership in the
+        role with <literal>ADMIN</literal> option, giving it the right to
+        grant membership in the
         new role to others.  Multiple roles to add as members (with admin
         option) of the new role can be specified by writing multiple
         <option>-a</option> switches.
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index 2fd0f34d55..8f0c572051 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -257,10 +257,10 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
   <para>
    If <literal>WITH ADMIN OPTION</literal> is specified, the member can
    in turn grant membership in the role to others, and revoke membership
-   in the role as well.  Without the admin option, ordinary users cannot
-   do that.  A role is not considered to hold <literal>WITH ADMIN
-   OPTION</literal> on itself.  Database superusers can grant or revoke
-   membership in any role to anyone.  Roles having
+   in the role as well.  Without the <literal>ADMIN</literal> option, ordinary
+   users cannot do that.  A role is not considered to hold
+   the <literal>ADMIN</literal> option on itself.  Database superusers can
+   grant or revoke membership in any role to anyone.  Roles having
    <literal>CREATEROLE</literal> privilege can grant or revoke membership
    in any role that is not a superuser.
   </para>
@@ -269,11 +269,11 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
    If <literal>GRANTED BY</literal> is specified, the grant is recorded as
    having been done by the specified role. A user can only attribute a grant
    to another role if they possess the privileges of that role. The role
-   recorded as the grantor must have <literal>ADMIN OPTION</literal> on the
+   recorded as the grantor must have <literal>ADMIN</literal> option on the
    target role, unless it is the bootstrap superuser. When a grant is recorded
    as having a grantor other than the bootstrap superuser, it depends on the
-   grantor continuing to posess <literal>ADMIN OPTION</literal> on the role;
-   so, if <literal>ADMIN OPTION</literal> is revoked, dependent grants must
+   grantor continuing to posess <literal>ADMIN</literal> option on the role;
+   so, if <literal>ADMIN</literal> option is revoked, dependent grants must
    be revoked as well.
   </para>
 
diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml
index 16e840458c..d783beaaa4 100644
--- a/doc/src/sgml/ref/revoke.sgml
+++ b/doc/src/sgml/ref/revoke.sgml
@@ -197,7 +197,7 @@ REVOKE [ ADMIN OPTION FOR ]
 
   <para>
    When revoking membership in a role, <literal>GRANT OPTION</literal> is instead
-   called <literal>ADMIN OPTION</literal>, but the behavior is similar.
+   called <literal>ADMIN</literal> option, but the behavior is similar.
    Note that, in releases prior to <productname>PostgreSQL</productname> 16,
    dependent privileges were not tracked for grants of role membership,
    and thus <literal>CASCADE</literal> had no effect for role membership.
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index 511ca8d8fd..f46a7ab930 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -41,7 +41,7 @@
 #include "utils/timestamp.h"
 
 /*
- * Removing a role grant - or the admin option on it - might recurse to
+ * Removing a role grant - or the ADMIN option on it - might recurse to
  * dependent grants. We use these values to reason about what would need to
  * be done in such cases.
  *
@@ -662,7 +662,7 @@ AlterRole(ParseState *pstate, AlterRoleStmt *stmt)
 	 * superuser.  We also insist on superuser to change the BYPASSRLS
 	 * property.  Otherwise, if you don't have createrole, you're only allowed
 	 * to (1) change your own password or (2) add members to a role for which
-	 * you have ADMIN OPTION.
+	 * you have ADMIN option.
 	 */
 	if (authform->rolsuper || dissuper)
 	{
@@ -704,7 +704,7 @@ AlterRole(ParseState *pstate, AlterRoleStmt *stmt)
 		if (drolemembers && !is_admin_of_role(GetUserId(), roleid))
 			ereport(ERROR,
 					(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-					 errmsg("must have admin option on role \"%s\" to add members",
+					 errmsg("must have ADMIN option on role \"%s\" to add members",
 							rolename)));
 	}
 
@@ -1483,7 +1483,7 @@ roleSpecsToIds(List *memberNames)
  * memberSpecs: list of RoleSpec of roles to add (used only for error messages)
  * memberIds: OIDs of roles to add
  * grantorId: who is granting the membership (InvalidOid if not set explicitly)
- * admin_opt: granting admin option?
+ * admin_opt: granting ADMIN option?
  */
 static void
 AddRoleMems(const char *rolename, Oid roleid,
@@ -1503,7 +1503,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 		return;
 
 	/*
-	 * Check permissions: must have createrole or admin option on the role to
+	 * Check permissions: must have CREATEROLE or ADMIN option on the role to
 	 * be changed.  To mess with a superuser role, you gotta be superuser.
 	 */
 	if (superuser_arg(roleid))
@@ -1519,7 +1519,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 			!is_admin_of_role(currentUserId, roleid))
 			ereport(ERROR,
 					(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-					 errmsg("must have admin option on role \"%s\"",
+					 errmsg("must have ADMIN option on role \"%s\"",
 							rolename)));
 	}
 
@@ -1543,7 +1543,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 
 	/*
 	 * Only allow changes to this role by one backend at a time, so that we
-	 * can check integrity constraints like the lack of circular ADMIN OPTION
+	 * can check integrity constraints like the lack of circular ADMIN option
 	 * grants without fear of race conditions.
 	 */
 	LockSharedObject(AuthIdRelationId, roleid, 0,
@@ -1562,7 +1562,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 		 * TO proposed_datdba" fail if is_member_of_role(pg_database_owner,
 		 * proposed_datdba).  Hence, gaining a membership could reduce what a
 		 * role could do.  Alternately, one could allow these memberships to
-		 * complete loops.  A role could then have actual WITH ADMIN OPTION on
+		 * complete loops.  A role could then have actual ADMIN option on
 		 * itself, prompting a decision about is_admin_of_role() treatment of
 		 * the case.
 		 *
@@ -1594,7 +1594,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 	}
 
 	/*
-	 * Disallow attempts to grant ADMIN OPTION back to a user who granted it
+	 * Disallow attempts to grant ADMIN option back to a user who granted it
 	 * to you, similar to what check_circularity does for ACLs. We want the
 	 * chains of grants to remain acyclic, so that it's always possible to use
 	 * REVOKE .. CASCADE to clean up all grants that depend on the one being
@@ -1603,8 +1603,8 @@ AddRoleMems(const char *rolename, Oid roleid,
 	 * NB: This check might look redundant with the check for membership loops
 	 * above, but it isn't. That's checking for role-member loop (e.g. A is a
 	 * member of B and B is a member of A) while this is checking for a
-	 * member-grantor loop (e.g. A gave ADMIN OPTION on X to B and now B, who
-	 * has no other source of ADMIN OPTION on X, tries to give ADMIN OPTION on
+	 * member-grantor loop (e.g. A gave ADMIN option on X to B and now B, who
+	 * has no other source of ADMIN option on X, tries to give ADMIN option on
 	 * X back to A).
 	 */
 	if (admin_opt && grantorId != BOOTSTRAP_SUPERUSERID)
@@ -1629,7 +1629,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 			if (memberid == BOOTSTRAP_SUPERUSERID)
 				ereport(ERROR,
 						(errcode(ERRCODE_INVALID_GRANT_OPERATION),
-						 errmsg("admin option cannot be granted back to your own grantor")));
+						 errmsg("ADMIN option cannot be granted back to your own grantor")));
 			plan_member_revoke(memlist, actions, memberid);
 		}
 
@@ -1654,7 +1654,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 		if (i >= memlist->n_members)
 			ereport(ERROR,
 					(errcode(ERRCODE_INVALID_GRANT_OPERATION),
-					 errmsg("admin option cannot be granted back to your own grantor")));
+					 errmsg("ADMIN option cannot be granted back to your own grantor")));
 
 		ReleaseSysCacheList(memlist);
 	}
@@ -1673,7 +1673,7 @@ AddRoleMems(const char *rolename, Oid roleid,
 
 		/*
 		 * Check if entry for this role/member already exists; if so, give
-		 * warning unless we are adding admin option.
+		 * warning unless we are adding ADMIN option.
 		 */
 		authmem_tuple = SearchSysCache3(AUTHMEMROLEMEM,
 										ObjectIdGetDatum(roleid),
@@ -1751,7 +1751,7 @@ AddRoleMems(const char *rolename, Oid roleid,
  * memberSpecs: list of RoleSpec of roles to del (used only for error messages)
  * memberIds: OIDs of roles to del
  * grantorId: who is revoking the membership
- * admin_opt: remove admin option only?
+ * admin_opt: remove ADMIN option only?
  * behavior: RESTRICT or CASCADE behavior for recursive removal
  */
 static void
@@ -1775,7 +1775,7 @@ DelRoleMems(const char *rolename, Oid roleid,
 		return;
 
 	/*
-	 * Check permissions: must have createrole or admin option on the role to
+	 * Check permissions: must have CREATEROLE or ADMIN option on the role to
 	 * be changed.  To mess with a superuser role, you gotta be superuser.
 	 */
 	if (superuser_arg(roleid))
@@ -1791,7 +1791,7 @@ DelRoleMems(const char *rolename, Oid roleid,
 			!is_admin_of_role(currentUserId, roleid))
 			ereport(ERROR,
 					(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-					 errmsg("must have admin option on role \"%s\"",
+					 errmsg("must have ADMIN option on role \"%s\"",
 							rolename)));
 	}
 
@@ -1862,7 +1862,7 @@ DelRoleMems(const char *rolename, Oid roleid,
 		}
 		else
 		{
-			/* Just turn off the admin option */
+			/* Just turn off the ADMIN option */
 			HeapTuple	tuple;
 			Datum		new_record[Natts_pg_auth_members] = {0};
 			bool		new_record_nulls[Natts_pg_auth_members] = {0};
@@ -1891,7 +1891,7 @@ DelRoleMems(const char *rolename, Oid roleid,
  * Sanity-check, or infer, the grantor for a GRANT or REVOKE statement
  * targeting a role.
  *
- * The grantor must always be either a role with ADMIN OPTION on the role in
+ * The grantor must always be either a role with ADMIN option on the role in
  * which membership is being granted, or the bootstrap superuser. This is
  * similar to the restriction enforced by select_best_grantor, except that
  * roles don't have owners, so we regard the bootstrap superuser as the
@@ -1901,8 +1901,8 @@ DelRoleMems(const char *rolename, Oid roleid,
  * be passed as InvalidOid, and this function will infer the user to be
  * recorded as the grantor. In many cases, this will be the current user, but
  * things get more complicated when the current user doesn't possess ADMIN
- * OPTION on the role but rather relies on having CREATEROLE privileges, or
- * on inheriting the privileges of a role which does have ADMIN OPTION. See
+ * option on the role but rather relies on having CREATEROLE privileges, or
+ * on inheriting the privileges of a role which does have ADMIN option. See
  * below for details.
  *
  * If the grantor was specified by the user, then it must be a user that
@@ -1931,7 +1931,7 @@ check_role_grantor(Oid currentUserId, Oid roleid, Oid grantorId, bool is_grant)
 			return BOOTSTRAP_SUPERUSERID;
 
 		/*
-		 * Otherwise, the grantor must either have ADMIN OPTION on the role or
+		 * Otherwise, the grantor must either have ADMIN option on the role or
 		 * inherit the privileges of a role which does. In the former case,
 		 * record the grantor as the current user; in the latter, pick one of
 		 * the roles that is "most directly" inherited by the current role
@@ -1951,7 +1951,7 @@ check_role_grantor(Oid currentUserId, Oid roleid, Oid grantorId, bool is_grant)
 	 * If an explicit grantor is specified, it must be a role whose privileges
 	 * the current user possesses.
 	 *
-	 * It should also be a role that has ADMIN OPTION on the target role, but
+	 * It should also be a role that has ADMIN option on the target role, but
 	 * we check this condition only in case of GRANT. For REVOKE, no matching
 	 * grant should exist anyway, but if it somehow does, let the user get rid
 	 * of it.
@@ -1968,7 +1968,7 @@ check_role_grantor(Oid currentUserId, Oid roleid, Oid grantorId, bool is_grant)
 			select_best_admin(grantorId, roleid) != grantorId)
 			ereport(ERROR,
 					(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
-					 errmsg("grantor must have ADMIN OPTION on \"%s\"",
+					 errmsg("grantor must have ADMIN option on \"%s\"",
 							GetUserNameFromId(roleid, false))));
 	}
 	else
@@ -2012,7 +2012,7 @@ initialize_revoke_actions(CatCList *memlist)
 
 /*
  * Figure out what we would need to do in order to revoke a grant, or just the
- * admin option on a grant, given that there might be dependent privileges.
+ * ADMIN option on a grant, given that there might be dependent privileges.
  *
  * 'memlist' should be a list of all grants for the target role.
  *
@@ -2126,7 +2126,7 @@ plan_recursive_revoke(CatCList *memlist, RevokeRoleGrantAction *actions,
 		actions[index] = RRG_REMOVE_ADMIN_OPTION;
 	}
 
-	/* Determine whether the member would still have ADMIN OPTION. */
+	/* Determine whether the member would still have ADMIN option. */
 	for (i = 0; i < memlist->n_members; ++i)
 	{
 		HeapTuple	am_cascade_tuple;
@@ -2143,7 +2143,7 @@ plan_recursive_revoke(CatCList *memlist, RevokeRoleGrantAction *actions,
 		}
 	}
 
-	/* If the member would still have ADMIN OPTION, we need not recurse. */
+	/* If the member would still have ADMIN option, we need not recurse. */
 	if (would_still_have_admin_option)
 		return;
 
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 3e045da31f..02f4744acb 100644
--- a/src/backend/utils/adt/acl.c
+++ b/src/backend/utils/adt/acl.c
@@ -4802,7 +4802,7 @@ has_rolinherit(Oid roleid)
  *
  * If admin_of is not InvalidOid, this function sets *admin_role, either
  * to the OID of the first role in the result list that directly possesses
- * ADMIN OPTION on the role corresponding to admin_of, or to InvalidOid if
+ * ADMIN option on the role corresponding to admin_of, or to InvalidOid if
  * there is no such role.
  */
 static List *
@@ -4819,7 +4819,7 @@ roles_is_member_of(Oid roleid, enum RoleRecurseType type,
 	if (admin_role != NULL)
 		*admin_role = InvalidOid;
 
-	/* If cache is valid and ADMIN OPTION not sought, just return the list */
+	/* If cache is valid and ADMIN option not sought, just return the list */
 	if (cached_role[type] == roleid && !OidIsValid(admin_of) &&
 		OidIsValid(cached_role[type]))
 		return cached_roles[type];
@@ -5013,7 +5013,7 @@ is_member_of_role_nosuper(Oid member, Oid role)
 
 /*
  * Is member an admin of role?	That is, is member the role itself (subject to
- * restrictions below), a member (directly or indirectly) WITH ADMIN OPTION,
+ * restrictions below), a member (directly or indirectly) with ADMIN option,
  * or a superuser?
  */
 bool
@@ -5024,7 +5024,7 @@ is_admin_of_role(Oid member, Oid role)
 	if (superuser_arg(member))
 		return true;
 
-	/* By policy, a role cannot have WITH ADMIN OPTION on itself. */
+	/* By policy, a role cannot have ADMIN option on itself. */
 	if (member == role)
 		return false;
 
@@ -5033,11 +5033,11 @@ is_admin_of_role(Oid member, Oid role)
 }
 
 /*
- * Find a role whose privileges "member" inherits which has ADMIN OPTION
+ * Find a role whose privileges "member" inherits which has ADMIN option
  * on "role", ignoring super-userness.
  *
  * There might be more than one such role; prefer one which involves fewer
- * hops. That is, if member has ADMIN OPTION, prefer that over all other
+ * hops. That is, if member has ADMIN option, prefer that over all other
  * options; if not, prefer a role from which member inherits more directly
  * over more indirect inheritance.
  */
@@ -5046,7 +5046,7 @@ select_best_admin(Oid member, Oid role)
 {
 	Oid			admin_role;
 
-	/* By policy, a role cannot have WITH ADMIN OPTION on itself. */
+	/* By policy, a role cannot have ADMIN option on itself. */
 	if (member == role)
 		return InvalidOid;
 
diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index e8a2bfa6bd..27ef96941a 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -956,7 +956,7 @@ dumpRoleMembership(PGconn *conn)
 	/*
 	 * Previous versions of PostgreSQL didn't used to track the grantor very
 	 * carefully in the backend, and the grantor could be any user even if
-	 * they didn't have ADMIN OPTION on the role, or a user that no longer
+	 * they didn't have ADMIN option on the role, or a user that no longer
 	 * existed. To avoid dump and restore failures, don't dump the grantor
 	 * when talking to an old server version.
 	 */
@@ -981,13 +981,13 @@ dumpRoleMembership(PGconn *conn)
 
 	/*
 	 * We can't dump these GRANT commands in arbitary order, because a role
-	 * that is named as a grantor must already have ADMIN OPTION on the
+	 * that is named as a grantor must already have ADMIN option on the
 	 * role for which it is granting permissions, except for the boostrap
 	 * superuser, who can always be named as the grantor.
 	 *
 	 * We handle this by considering these grants role by role. For each role,
 	 * we initially consider the only allowable grantor to be the boostrap
-	 * superuser. Every time we grant ADMIN OPTION on the role to some user,
+	 * superuser. Every time we grant ADMIN option on the role to some user,
 	 * that user also becomes an allowable grantor. We make repeated passes
 	 * over the grants for the role, each time dumping those whose grantors
 	 * are allowable and which we haven't done yet. Eventually this should
@@ -1072,7 +1072,7 @@ dumpRoleMembership(PGconn *conn)
 				--remaining;
 
 				/*
-				 * If ADMIN OPTION is being granted, remember that grants
+				 * If ADMIN option is being granted, remember that grants
 				 * listing this member as the grantor can now be dumped.
 				 */
 				if (*admin_option == 't')
diff --git a/src/bin/scripts/t/040_createuser.pl b/src/bin/scripts/t/040_createuser.pl
index 834d258bf8..a9de57f3b7 100644
--- a/src/bin/scripts/t/040_createuser.pl
+++ b/src/bin/scripts/t/040_createuser.pl
@@ -39,7 +39,7 @@ $node->issues_sql_like(
 		'regress user2', 'regress user #4'
 	],
 	qr/statement: CREATE ROLE "regress user #4" NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN ADMIN regress_user1,"regress user2";/,
-	'add a role as a member with admin option of the newly created role');
+	'add a role as a member with ADMIN option of the newly created role');
 $node->issues_sql_like(
 	[
 		'createuser',      '-m',
diff --git a/src/include/catalog/pg_auth_members.h b/src/include/catalog/pg_auth_members.h
index e57ec4f810..f0e04baadd 100644
--- a/src/include/catalog/pg_auth_members.h
+++ b/src/include/catalog/pg_auth_members.h
@@ -33,7 +33,7 @@ CATALOG(pg_auth_members,1261,AuthMemRelationId) BKI_SHARED_RELATION BKI_ROWTYPE_
 	Oid			roleid BKI_LOOKUP(pg_authid);	/* ID of a role */
 	Oid			member BKI_LOOKUP(pg_authid);	/* ID of a member of that role */
 	Oid			grantor BKI_LOOKUP(pg_authid);	/* who granted the membership */
-	bool		admin_option;	/* granted with admin option? */
+	bool		admin_option;	/* granted with ADMIN option? */
 } FormData_pg_auth_members;
 
 /* ----------------
diff --git a/src/test/regress/expected/privileges.out b/src/test/regress/expected/privileges.out
index 0154a09262..56981c85c8 100644
--- a/src/test/regress/expected/privileges.out
+++ b/src/test/regress/expected/privileges.out
@@ -37,7 +37,7 @@ CREATE ROLE regress_priv_role;
 GRANT regress_priv_user1 TO regress_priv_user2 WITH ADMIN OPTION;
 GRANT regress_priv_user1 TO regress_priv_user3 WITH ADMIN OPTION GRANTED BY regress_priv_user2;
 GRANT regress_priv_user1 TO regress_priv_user2 WITH ADMIN OPTION GRANTED BY regress_priv_user3;
-ERROR:  admin option cannot be granted back to your own grantor
+ERROR:  ADMIN option cannot be granted back to your own grantor
 -- need CASCADE to revoke grant or admin option if dependent grants exist
 REVOKE ADMIN OPTION FOR regress_priv_user1 FROM regress_priv_user2; -- fail
 ERROR:  dependent privileges exist
@@ -159,7 +159,7 @@ CREATE FUNCTION leak(integer,integer) RETURNS boolean
 ALTER FUNCTION leak(integer,integer) OWNER TO regress_priv_user1;
 -- test owner privileges
 GRANT regress_priv_role TO regress_priv_user1 WITH ADMIN OPTION GRANTED BY regress_priv_role; -- error, doesn't have ADMIN OPTION
-ERROR:  grantor must have ADMIN OPTION on "regress_priv_role"
+ERROR:  grantor must have ADMIN option on "regress_priv_role"
 GRANT regress_priv_role TO regress_priv_user1 WITH ADMIN OPTION GRANTED BY CURRENT_ROLE;
 REVOKE ADMIN OPTION FOR regress_priv_role FROM regress_priv_user1 GRANTED BY foo; -- error
 ERROR:  role "foo" does not exist
@@ -1774,7 +1774,7 @@ REFRESH MATERIALIZED VIEW sro_mv;
 ERROR:  cannot fire deferred trigger within security-restricted operation
 CONTEXT:  SQL function "mv_action" statement 1
 BEGIN; SET CONSTRAINTS ALL IMMEDIATE; REFRESH MATERIALIZED VIEW sro_mv; COMMIT;
-ERROR:  must have admin option on role "regress_priv_group2"
+ERROR:  must have ADMIN option on role "regress_priv_group2"
 CONTEXT:  SQL function "unwanted_grant" statement 1
 SQL statement "SELECT unwanted_grant()"
 PL/pgSQL function sro_trojan() line 1 at PERFORM
@@ -1804,10 +1804,10 @@ CREATE FUNCTION dogrant_ok() RETURNS void LANGUAGE sql SECURITY DEFINER AS
 GRANT regress_priv_group2 TO regress_priv_user5; -- ok: had ADMIN OPTION
 SET ROLE regress_priv_group2;
 GRANT regress_priv_group2 TO regress_priv_user5; -- fails: SET ROLE suspended privilege
-ERROR:  must have admin option on role "regress_priv_group2"
+ERROR:  must have ADMIN option on role "regress_priv_group2"
 SET SESSION AUTHORIZATION regress_priv_user1;
 GRANT regress_priv_group2 TO regress_priv_user5; -- fails: no ADMIN OPTION
-ERROR:  must have admin option on role "regress_priv_group2"
+ERROR:  must have ADMIN option on role "regress_priv_group2"
 SELECT dogrant_ok();			-- ok: SECURITY DEFINER conveys ADMIN
 NOTICE:  role "regress_priv_user5" has already been granted membership in role "regress_priv_group2" by role "regress_priv_user4"
  dogrant_ok 
@@ -1817,10 +1817,10 @@ NOTICE:  role "regress_priv_user5" has already been granted membership in role "
 
 SET ROLE regress_priv_group2;
 GRANT regress_priv_group2 TO regress_priv_user5; -- fails: SET ROLE did not help
-ERROR:  must have admin option on role "regress_priv_group2"
+ERROR:  must have ADMIN option on role "regress_priv_group2"
 SET SESSION AUTHORIZATION regress_priv_group2;
 GRANT regress_priv_group2 TO regress_priv_user5; -- fails: no self-admin
-ERROR:  must have admin option on role "regress_priv_group2"
+ERROR:  must have ADMIN option on role "regress_priv_group2"
 SET SESSION AUTHORIZATION regress_priv_user4;
 DROP FUNCTION dogrant_ok();
 REVOKE regress_priv_group2 FROM regress_priv_user5;
