## Code Analysis

### Default-privilege catalog is hard-coded empty
`server/tables/pgcatalog/pg_default_acl.go:44-50`
```go
func (p PgDefaultAclHandler) RowIter(ctx *sql.Context, partition sql.Partition) (sql.RowIter, error) {
	// pg_default_acl is currently empty, since ALTER DEFAULT PRIVILEGES is not supported.
	// This table is also empty in vanilla Postgres until default privileges are altered.
	// TODO: fill this in when ALTER DEFAULT PRIVILEGES is supported
	return emptyRowIter()
}
```
The catalog handler returns an empty iterator for every query, so configured default privileges cannot appear in `pg_default_acl`.

### Routine ACL projection is always NULL
`server/tables/pgcatalog/pg_proc.go:328-358`
```go
return sql.Row{
	// ... routine metadata ...
	nil,          // proconfig
	nil,          // proacl
}, nil
```
The `proacl` field is emitted as `nil` for every routine. This explains why a created function can exist while its SQL-visible routine ACL remains empty.

### Internal routine-default application exists
`server/auth/default_privileges.go:293-332`
```go
func ApplyDefaultPrivilegesForNewRoutine(ownerRoleID RoleID, schemaName, routineName string) bool {
	// ... matching global and schema-specific defaults are selected ...
	for granteeID, granteeValue := range dpv.Grantees {
		for _, privilegeMap := range granteeValue.Privileges {
			for grantedPriv, withGrantOption := range privilegeMap {
				applied = true
				AddRoutinePrivilege(RoutinePrivilegeKey{
					Role: granteeID, Schema: schemaName, Name: routineName,
				}, grantedPriv, withGrantOption)
			}
		}
	}
	return applied
}
```
The internal path does select matching global and schema-specific function defaults and adds routine privileges. The defect evidenced here is that the SQL catalog projections do not expose the resulting state.

### Result
Source analysis supports the reported catalog observability defect: default privileges can be accepted and applied internally, while `pg_default_acl` returns no rows and `pg_proc.proacl` is always NULL.

## Observed SQL Evidence

### Initial function and ACL readback
```text
$ docker exec ... psql ... -c "SET ROLE privilege7_owner; CREATE OR REPLACE FUNCTION privilege_batch7.f_global_schema() RETURNS int LANGUAGE SQL AS $$ SELECT 27 $$; SELECT p.proname, p.proacl FROM pg_proc p JOIN pg_namespace n ON n.oid=p.pronamespace WHERE n.nspname='privilege_batch7' AND p.proname='f_global_schema';"
CREATE FUNCTION
     proname     | proacl
----------------+--------
 f_global_schema |
(1 row)
```

### Default-privilege catalog readback
```text
ALTER DEFAULT PRIVILEGES
 oid | defaclrole | defaclnamespace | defaclobjtype | defaclacl
-----+------------+-----------------+---------------+-----------
(0 rows)
```

### Revoke-and-create comparison
```text
SET
ALTER DEFAULT PRIVILEGES
CREATE FUNCTION
    proname     | proacl
----------------+--------
 f_after_revoke |
(1 row)
```
The captured readbacks show successful function creation but blank ACL output and zero visible default-ACL rows after the default-permission commands.

### Effective privilege check unavailable
```text
ERROR:  function: 'has_function_privilege' not found
```
This prevented an independent runtime assertion of effective function authorization. The evidence supports the missing catalog visibility, not a proven authorization bypass.

### Test context
The target was a PostgreSQL wire service rather than an HTTP page; browser navigation errors are not included as product evidence. The runner repaired schema access with explicit `USAGE` and `CREATE` grants before the successful function creation.