CockroachDB 23.1.11 shows default privileges from the recipient side
FOR GRANTEE adds a recipient-oriented view of default privileges. It complements creator-oriented inspection without claiming to show every effective permission on existing objects.
An administrator investigating a role's access usually begins with the recipient. Default-privilege configuration is often organized around a different question, which role will create the future object. CockroachDB 23.1.11 adds SHOW DEFAULT PRIVILEGES FOR GRANTEE so that inspection can begin with the user or role receiving those defaults. That reduces the mismatch between the question an administrator has and the direction in which the configuration is stored.
The October 2 release notes describe the new syntax as showing the default privileges a grantee received. The 23.1 statement documentation distinguishes it from the existing FOR ROLE and FOR USER forms. Those forms select defaults for objects created by the named role, while FOR GRANTEE selects the recipient.
I value database interfaces that make authorization inspectable without requiring broad administrative powers. This addition is useful because a role's future access can depend on defaults configured by several creators. The recipient-oriented view expresses that investigation directly.
Creator and recipient are different roles in the statement
Without a FOR clause, the documentation says the command returns defaults for objects created by the current user. Adding FOR ROLE name or FOR USER name changes that creator selection. It does not mean show everything the named user receives from other creators.
That distinction is easy to miss because the same person can create objects and receive privileges on other objects. The relevant position in the default-privilege rule matters. A user named in the creator field and the same user named as grantee answer different questions about future objects.
The new statement makes the recipient explicit. For an illustrative role named report_reader, inspection has this form.
SHOW DEFAULT PRIVILEGES FOR GRANTEE report_reader;
This is an inspection command. It does not grant report_reader any privileges, change the creators' defaults or modify existing tables. The release adds a view of the rules, rather than a different rule for assigning access.
The documentation requires the inspecting user to have some privilege on the current database. That scope also matters. The command describes defaults in that database, so a result from one connection context should not be presented as an inventory across every database in the cluster.
The output preserves the source of the default
The documented output identifies a role, whether the rule applies for all roles, an object type, a grantee and a privilege type. Its grantee example also includes is_grantable. These fields keep the recipient view connected to the configuration that produced it, rather than reducing the result to a list of permission names with no origin.
Object type is significant because defaults can differ for tables, schemas or types. A default granting access to one category is not a grant on every kind of database object. The statement's output retains that distinction so an administrator can see what future object creation the rule concerns.
Schema scope supplies another dimension. The documentation demonstrates setting defaults within a selected schema and inspecting them with IN SCHEMA. That is useful when a database contains separately managed namespaces. It prevents a local configuration from being mistaken for a database-wide rule merely because the same recipient appears in both discussions.
A default-privilege view also differs from inspecting current object grants. The statement describes rules for objects created under the relevant defaults. Existing objects can have their own grant histories. The new recipient filter does not establish a complete effective-access calculation across every current object and every role membership.
My preference is to preserve that limit in permission reviews. The new query answers where a recipient appears in default policy. An inventory of actual table access remains a separate question, even when the same role names appear in both results.
Other changes improve administrative evidence
The release also corrects catalog ownership reporting for tables in pg_catalog and information_schema. Introspection now identifies the internal node user as owner instead of admin. The notes explain that showing admin was inaccurate because users in that role could not modify those tables.
That correction and the grantee filter address a related problem. Administrative output should describe the permission relationship the server actually implements. A misleading owner field or a creator-oriented filter mistaken for a recipient filter can each lead to an incorrect conclusion without any failure of the underlying SQL grant check.
Version 23.1.11 separately adds VIEWSYSTEMTABLE, granting selection access to tables in the system database. That is an authority change, while FOR GRANTEE is an inspection change. Keeping them separate avoids implying that using the new inspection syntax requires or automatically supplies the new system-wide selection privilege.
The resulting command gives administrators a direct starting point for recipient-oriented default-policy analysis. Its output retains creator and object-type context, while the current database bounds the result. Those details make the new filter useful without extending its meaning to permissions it does not calculate.