在使用Hologres開發時，可能會因為許可權問題產生報錯。本文內容將為您介紹幾個Hologres執行個體開發常見許可權問題的解決方案。
問題匯總
- 如何選擇合適的Hologres許可權模型？
- 在Hologres執行個體內操作報錯：role “RAM$xxx” doesn't not exsit
- 串連執行個體時報錯：Cloud authentication failed for access id "xxxx"
- 查詢表時報錯： permission denied for table xxxx
- 在Hologres執行個體內操作報錯：permission denied for database“xxx” detail：user does not have CONNECT privilege
- 使用call spm_enable()命令時，提示：because roles conflict
- 授權時報錯：current database is NOT in simple privilege mode
- 動作表時報錯：must be the owner of table xxxx
- 跨Schema建立視圖時查詢報錯： permission denied for table xxx
- 執行SQL時報錯：permission denied for Schema xxx
- 執行SQL報錯：ALTER TABLE xxx is not supported in Simple Privilege Mode
如何選擇合適的Hologres許可權模型？
- 專家許可權模型指的是Postgres原生的許可權模型，若您對Postgres及其許可權管理已經比較熟悉，可以零學習成本使用專家許可權模型實現授權操作。如果您需要細粒度到表層級的許可權管理，並且有充足的時間、精力和必要性對每個表、每個使用者進行許可權賦予、回收等操作可以使用專家許可權模型。
- 簡單許可權模型（簡稱SPM）指的是DB層級的簡單許可權管理模型，所有需要訪問DB的使用者都需要加入到某個使用者組中，每個使用者組都有DB中任意Schema下對象特定的存取權限。如果您很少採用Schema進行開發，或者只是像使用目錄一樣採用Schema對錶對象進行分類，而無需Schema層級的許可權隔離，推薦您使用簡單許可權模型SPM。
- 基於Schema層級的簡單許可權模型（簡稱SLPM），每個Schema都有自己的developer、writer、viewer使用者組。若您強依賴Schema層級的使用者隔離，表許可權隔離，推薦您使用SLPM。
在Hologres執行個體內操作報錯：role “RAM$xxx” doesn't not exsit
- 問題現象
串連開發工具之後，在執行個體內進行查詢等操作時報錯提示：role “RAM$xxx” doesn't not exsit。
- 問題原因
當前RAM使用者帳號未被建立進執行個體中。
- 解決方案
您可以根據業務情況，為當前RAM使用者帳號授予執行個體的相關許可權，如Superuser。更詳細的授權請參見授予RAM使用者執行個體的開發許可權。
串連執行個體時報錯：Cloud authentication failed for access id "xxxx"
- 問題現象
在串連開發工具時報錯提示Cloud authentication failed for access id "xxxx"。
- 問題原因
當前帳號填寫的密碼錯誤。
- 解決方案
您需要檢查當前串連的密碼，需要確保密碼為Access key且不包含空格。更多關於Access key的詳細內容請參見建立存取金鑰。
查詢表時報錯： permission denied for table xxxx
- 問題現象
在執行個體內進行查詢等操作時報錯提示Execution failed：ERROR: permission denied for table xxxx。
- 問題原因
當前帳號沒有對應表的查看許可權。
- 解決方案
您可以根據當前授權模式的不同，選擇對應的解決方案。
- 專家許可權模式授權：執行如下命令為使用者授權，其中p4_UID為RAM使用者的帳號資訊。更多專家許可權模式的資訊，請參見專家許可權模型。
grant select on table tablename to "p4_UID"; - 簡單許可權模型：將目前使用者加入viewer及以上使用者組。具體操作請參見簡單許可權模型的使用。
- 專家許可權模式授權：執行如下命令為使用者授權，其中p4_UID為RAM使用者的帳號資訊。更多專家許可權模式的資訊，請參見專家許可權模型。
在Hologres執行個體內操作報錯：permission denied for database“xxx” detail：user does not have CONNECT privilege
- 問題現象
串連開發工具之後，在執行個體內進行查詢等操作時報錯提示FATAL:permission denied for database“xxx” detail：user does not have CONNECT privilege。
- 問題原因
當前帳號只被建立進了執行個體中，但是沒有對應執行個體的開發許可權。
- 解決方案
您可以根據業務情況，為目前使用者帳號授予執行個體的相關許可權，如Superuser。更詳細的授權請參見授予RAM使用者執行個體的開發許可權。
使用call spm_enable()命令時，提示：because roles conflict
- 問題現象
在專家模式下，執行
call spm_enable()會提示：because roles conflict類似報錯。 - 問題原因
是因為當前資料庫之前開啟過簡單模式，存在殘留資訊。
- 解決方案
您需要執行
call spm_enable ('t');開啟。
授權時報錯：current database is NOT in simple privilege mode
- 問題現象
進行授權操作時，報錯：current database is NOT in simple privilege mode。
- 問題原因
當前資料庫未開啟簡單許可權模型。
- 解決方案
- 請執行
show hg_experimental_enable_spm;命令檢查是否關閉了簡單許可權模型。 - 使用如下命令開啟當前資料庫的簡單許可權模型。
-- 開啟當前DB的簡單許可權模型 call spm_enable ('t'); -- 將DB中已有的對象change owner到develoepr，使用SPM管理 call spm_migrate ();call spm_enable ('t');括弧裡't'的含義：將call spm_disable關掉後，原系統角色不會刪除，會繼續保留這些角色和許可權。如果下次使用spm_enable()不帶t，就會顯示角色衝突，而無法開啟。spm_enable ('t')就是忽略這個衝突，繼續重用這些系統角色。
- 請執行
動作表時報錯：must be the owner of table xxxx
- 問題現象
在執行個體內進行操作時報錯提示：must be the owner of table xxxx。
- 問題原因
當前RAM使用者不是表的owner，無法建立分區子表或者執行刪除表的操作。
- 解決方案
您可以根據當前授權模式的不同，選擇對應的解決方案。
- 專家許可權模式授權：執行如下命令將表的owner授予當前帳號，其中p4_UID為RAM使用者的帳號資訊。更多專家許可權模式的資訊，請參見專家許可權模型。
alter table tablename owner to "p4_UID"; - 簡單許可權模型：將目前使用者加入developer及以上使用者組。具體操作請參見簡單許可權模型的使用。
- 專家許可權模式授權：執行如下命令將表的owner授予當前帳號，其中p4_UID為RAM使用者的帳號資訊。更多專家許可權模式的資訊，請參見專家許可權模型。
跨Schema建立視圖時查詢報錯： permission denied for table xxx
- 問題原因
執行個體開啟了Schema層級的簡單許可權模型（SLPM），當前SLPM不支援跨Schema建立視圖。
- 解決方案
您需要檢查是否在SLPM模型下跨Schema建立視圖。
執行SQL時報錯：permission denied for Schema xxx
- 報錯原因
目前使用者沒有Schema的許可權，導致查詢報錯。
- 解決方案
您需要確認目前使用者的許可權模型，選擇對應的解決方案。
- 若是SPM或者SLPM許可權模型，查詢時需要將使用者加入到Viewer及以上的使用者組，建表時報錯需要將使用者加入到Developer及以上的使用者組，詳情請參見SPM授權、SLPM授權。
- 若是專家許可權模型，需要顯示給使用者授予Schema的查詢許可權，可以根據業務需求為使用者授予相關的許可權，詳情請參見專家許可權模型。使用如下命令授予Schema的查詢許可權：
-- 授予SCHEMA使用許可權（展示SCHEMA的所有表） GRANT USAGE ON SCHEMA <schema_name> TO "雲帳號/雲郵箱"; -- 授予在SCHEMA上建立表的許可權 GRANT CREATE ON SCHEMA <schema_name> TO "雲帳號/雲郵箱";