Redshift超级用户访问视图遇permission denied for relation问题排查

针对你遇到的问题，可从以下几个方向排查解决：

1. 确认核心前提 #

• 检查当前执行查询的用户确实是超级用户：

  SELECT usesuper FROM pg_user WHERE usename = current_user;
  

  返回t才是超级用户，若为f则需要先提升用户权限。
• 验证视图定义未被篡改：

  SELECT definition FROM pg_views WHERE schemaname = 'processed' AND viewname = 'sales';
  

  确保结果确实是SELECT * FROM source."sales"。

2. 排查WITH NO SCHEMA BINDING的特性影响 #

这个选项会让视图不绑定底层表的权限，查询视图时使用当前执行用户的权限访问source.sales，而非视图所有者的权限。即使是超级用户，也需要确认：

• 当前用户对source.sales确实有SELECT权限（可通过psql命令\dp source.sales或查询pg_class.relacl字段再次验证）。
• 若source.sales开启了行级安全策略（RLS），需检查超级用户是否拥有BYPASSRLS属性：

  -- 检查表是否启用RLS
  SELECT relrowsecurity FROM pg_class WHERE relname = 'sales' AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'source');
  -- 检查用户是否有BYPASSRLS权限
  SELECT usebypassrls FROM pg_user WHERE usename = current_user;
  

  若RLS启用且用户无BYPASSRLS，执行以下命令赋予权限：

  ALTER USER your_superuser_name WITH BYPASSRLS;
  

3. 验证视图与Schema的权限 #

• 检查processed Schema是否给当前用户开放了USAGE权限：

  SELECT * FROM pg_namespace WHERE nspname = 'processed';
  

  查看nspacl字段，确认超级用户有USAGE权限（默认超级用户拥有所有权限，但若被显式撤销则需重新授权）。
• 检查视图本身的权限：

  \dp processed.sales
  

  确保超级用户有SELECT权限（虽然默认应有，但以防被意外撤销）。

关于“修改视图所有者”的怀疑 #

修改视图所有者本身不会导致超级用户权限被拒，除非修改所有者时同时移除了公共权限且未给超级用户单独授权，但这种情况概率极低——因为超级用户默认拥有所有数据库对象的权限。

内容的提问来源于stack exchange，提问作者SimonB