| name | hologres-privileges |
| description | Hologres privilege management using PostgreSQL standard authorization model (expert permission model).
Use for creating users, granting/revoking Schema/table/column/view privileges, configuring default
privileges for future objects, diagnosing permission issues, and planning role-based access control.
Triggers: "hologres权限", "hologres grant", "hologres revoke", "permission denied", "权限管理",
"hologres privileges", "hologres authorization", "default privileges", "角色权限", "授权"
|
Prerequisites
This skill requires hologres-cli to be installed first:
pip install hologres-cli
export HOLOGRES_SKILL=hologres-privileges
All SQL execution depends on hologres-cli commands (hologres sql run --write).
Hologres Privilege Management (Expert Permission Model)
Manage fine-grained access control in Hologres using standard PostgreSQL GRANT/REVOKE syntax.
Permission Model Overview
Hologres provides three permission models. This skill focuses on the Expert Model.
| Model | Granularity | Use Case |
|---|
| Expert (PostgreSQL Standard) | Table/Column/View level | Fine-grained control, per-table/per-user |
| SPM (Simple Permission Model) | Database level | Quick setup, 4 preset role groups |
| SLPM (Schema-Level Permission Model) | Schema level | Multi-team isolation with simplified management |
The expert model uses standard PostgreSQL GRANT/REVOKE syntax. It only applies to existing objects — use ALTER DEFAULT PRIVILEGES for future objects.
Quick Start
CREATE USER "p4_1822780xxx";
GRANT USAGE ON SCHEMA public TO "p4_1822780xxx";
GRANT SELECT ON TABLE public.orders TO "p4_1822780xxx";
SELECT has_table_privilege('p4_1822780xxx', 'public.orders', 'SELECT');
User Management
Account Types
| Type | Format | Example |
|---|
| Alibaba Cloud main account | Numeric UID | 11822780xxx |
| RAM sub-account | p4_ + UID | p4_1822780xxx |
| Custom user (BASIC) | BASIC$ + name | BASIC$dev_user |
Create Users
CREATE USER "p4_1822780xxx";
CREATE USER "p4_1822780xxx" SUPERUSER;
CREATE USER "BASIC$dev_user" WITH PASSWORD 'secure_password';
Alter Users
ALTER USER "p4_1822780xxx" SUPERUSER;
ALTER USER "p4_1822780xxx" NOSUPERUSER;
ALTER USER "BASIC$dev_user" WITH PASSWORD 'new_password';
Delete Users
DROP USER "p4_1822780xxx";
REASSIGN OWNED BY "p4_old_uid" TO "p4_new_uid";
DROP USER "p4_old_uid";
Core Grant Syntax
Schema Privileges
GRANT USAGE ON SCHEMA schema_name TO "user_id";
GRANT CREATE ON SCHEMA schema_name TO "user_id";
Table Privileges
GRANT SELECT ON TABLE schema_name.table_name TO "user_id";
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE schema_name.table_name TO "user_id";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "user_id";
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO PUBLIC;
Column Privileges
GRANT SELECT (column1, column2) ON TABLE schema_name.table_name TO "user_id";
View Privileges
GRANT SELECT ON view_name TO "user_id";
Grant with Transfer (WITH GRANT OPTION)
GRANT SELECT ON TABLE schema_name.table_name TO "user_id" WITH GRANT OPTION;
Owner Transfer
Only the table Owner or Superuser can DROP/ALTER a table.
ALTER TABLE schema_name.table_name OWNER TO "user_id";
ALTER TABLE schema_name.table_name OWNER TO role_name;
Default Privileges (Future Objects)
GRANT only applies to existing objects. Use ALTER DEFAULT PRIVILEGES so that future tables automatically inherit permissions.
ALTER DEFAULT PRIVILEGES FOR ROLE "user1" IN SCHEMA public
GRANT SELECT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES FOR ROLE "user1" IN SCHEMA public
GRANT SELECT ON TABLES TO "user2";
ALTER DEFAULT PRIVILEGES FOR ROLE "user1" IN SCHEMA public
REVOKE SELECT ON TABLES FROM PUBLIC;
SELECT pg_catalog.pg_get_userbyid(d.defaclrole) AS "Owner",
n.nspname AS "Schema",
CASE d.defaclobjtype
WHEN 'r' THEN 'table' WHEN 'S' THEN 'sequence'
WHEN 'f' THEN 'function' WHEN 'T' THEN 'type'
END AS "Type",
pg_catalog.array_to_string(d.defaclacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_default_acl d
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.defaclnamespace
ORDER BY 1, 2, 3;
Important: ALTER DEFAULT PRIVILEGES FOR ROLE "X" only applies when user X creates the object. If another user creates tables, the rule does not trigger.
Revoke Privileges
| Scope | SQL |
|---|
| Single table | REVOKE SELECT ON TABLE schema.table FROM "user_id"; |
| All tables in Schema | REVOKE ALL ON ALL TABLES IN SCHEMA public FROM "user_id"; |
| Schema access | REVOKE USAGE ON SCHEMA schema_name FROM "user_id"; |
| Column privilege | REVOKE SELECT (col1) ON TABLE schema.table FROM "user_id"; |
Permission Diagnostics Quick Reference
SELECT rolname, rolsuper, rolcanlogin FROM pg_roles;
SELECT has_table_privilege('user_id', 'schema.table', 'SELECT');
SELECT table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'user_id';
SELECT rolname FROM pg_roles
WHERE has_table_privilege(rolname, 'schema.table', 'SELECT');
For more diagnostic queries, see diagnostic-queries.md.
Common Errors and Troubleshooting
| Error | Cause | Solution |
|---|
permission denied for table xxx | Missing table privilege | GRANT SELECT ON TABLE xxx TO "user"; |
must be the owner of table xxx | Non-owner attempting DDL | ALTER TABLE xxx OWNER TO "user"; |
permission denied for Schema xxx | Missing Schema USAGE | GRANT USAGE ON SCHEMA xxx TO "user"; |
References
Best Practices
- Never use the main account for business queries — create dedicated users
- Always GRANT USAGE ON SCHEMA first — without it, no table queries work
- Use role groups instead of per-user grants — create
project_dev, project_write, project_view roles
- Use ALTER DEFAULT PRIVILEGES for future tables — combine with
GRANT ON ALL TABLES for existing tables
- Regularly audit permissions with diagnostic SQL from diagnostic-queries.md
- Transfer ownership before dropping users — use
REASSIGN OWNED BY
- Enable catalog RLS on V3.0+ to protect metadata visibility (
hg_experimental_enable_catalog_rls)