terrymanu commented on issue #33347:
URL: 
https://github.com/apache/shardingsphere/issues/33347#issuecomment-3565435140

   • Problem Understanding
   
     - On ShardingSphere-JDBC 5.1.2 with Aurora PostgreSQL 14.11, application 
user user1 is not the table owner. Querying sharded tables raises an NPE in 
MyBatis, indicating metadata fetch failure.
   
     Root Cause
   
     - ShardingSphere loads PG metadata by querying 
information_schema.role_table_grants and information_schema.columns. If the 
current user lacks explicit privileges on the tables/sequences, these 
information-
       schema views filter out the tables, so ShardingSphere cannot obtain 
column/index/constraint metadata, leading to NPE in later binding/result 
handling.
     - Aurora PostgreSQL 14 behaves like community PostgreSQL 14 for 
information-schema visibility. Because Aurora has no true superuser 
(rds_superuser is still constrained by ACL), missing grants more readily
       results in “metadata not visible.”
   
     Analysis
   
     - Grant the connecting user explicit schema/table/sequence privileges. 
Minimal example (replace schema/table as needed):
   
       GRANT USAGE ON SCHEMA public TO user1;
       GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA public TO user1;
       GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO user1;
       ALTER DEFAULT PRIVILEGES FOR ROLE user2 IN SCHEMA public GRANT SELECT, 
REFERENCES ON TABLES TO user1;
     - Verify visibility using the connecting user:
   
       SELECT table_schema, table_name, privilege_type
       FROM information_schema.role_table_grants
       WHERE grantee = current_user AND table_name = '<logical_table_name>';
   
       SELECT table_schema, table_name
       FROM information_schema.columns
       WHERE table_name = '<logical_table_name>';
       If no rows are returned, privileges are insufficient.
     - ShardingSphere targets standard PostgreSQL semantics; if the target 
database diverges from standard PG behavior, custom extensions may be needed to 
adapt to its privilege/catalog behavior.
   
     Conclusion
   
     - The observed NPE stems from missing privileges causing 
information-schema invisibility, not from a confirmed product defect. Please 
grant the privileges above and retry.
     - Official documentation: PostgreSQL 14 information schema and visibility 
https://www.postgresql.org/docs/14/information-schema.html , privilege 
management https://www.postgresql.org/docs/14/ddl-priv.html .
     - If NPE persists after granting, please share the full stack trace 
(including ShardingSphere class names) and the results of the two verification 
queries above for further diagnosis.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to