Skip to content

Conversation

@iPeluwa
Copy link
Contributor

@iPeluwa iPeluwa commented Dec 16, 2025

Fixes #191

This change decouples AuthManager from PgCatalogContextProvider to unblock issue #189 (moving pg_catalog to a separate module).

Changes:

  • Add RoleProvider trait for providing role information to pg_catalog
  • Implement RoleProvider for AuthManager and Arc
  • Add RoleProviderBridge adapter that wraps RoleProvider and implements PgCatalogContextProvider - this bridges the two worlds without tight coupling
  • Remove direct PgCatalogContextProvider impl from AuthManager
  • Update testing.rs and CLI to use RoleProviderBridge

The architecture now looks like:
AuthManager -> RoleProvider trait RoleProviderBridge -> PgCatalogContextProvider trait pg_catalog uses PgCatalogContextProvider for pg_roles table

This keeps auth concerns separate from pg_catalog while still allowing role information to flow to the pg_roles table.

iPeluwa and others added 2 commits December 16, 2025 07:43
Fixes datafusion-contrib#191

This change decouples AuthManager from PgCatalogContextProvider to
unblock issue datafusion-contrib#189 (moving pg_catalog to a separate module).

Changes:
- Add RoleProvider trait for providing role information to pg_catalog
- Implement RoleProvider for AuthManager and Arc<T>
- Add RoleProviderBridge adapter that wraps RoleProvider and implements
  PgCatalogContextProvider - this bridges the two worlds without
  tight coupling
- Remove direct PgCatalogContextProvider impl from AuthManager
- Update testing.rs and CLI to use RoleProviderBridge

The architecture now looks like:
  AuthManager -> RoleProvider trait
  RoleProviderBridge -> PgCatalogContextProvider trait
  pg_catalog uses PgCatalogContextProvider for pg_roles table

This keeps auth concerns separate from pg_catalog while still allowing
role information to flow to the pg_roles table.
@iPeluwa
Copy link
Contributor Author

iPeluwa commented Dec 17, 2025

@sunng87 Could you please review this ?

@sunng87
Copy link
Member

sunng87 commented Dec 17, 2025

@iPeluwa I thought I comment about this but I forgot to hit send button. I think this has some overlap with PgCatalogContextProvider. The idea of PgCatalogContextProvider is to decouple AuthManager with our pg_catalog. It's already done. I don't we need one more layer between them.

@iPeluwa
Copy link
Contributor Author

iPeluwa commented Dec 18, 2025

@iPeluwa I thought I comment about this but I forgot to hit send button. I think this has some overlap with PgCatalogContextProvider. The idea of PgCatalogContextProvider is to decouple AuthManager with our pg_catalog. It's already done. I don't we need one more layer between them.

Thanks for the feedback! You're right - I see now that PgCatalogContextProvider was already designed as the abstraction layer to decouple auth from pg_catalog.

Looking at it again, the actual coupling I was trying to address was that AuthManager in datafusion-postgres had to directly import from datafusion-pg-catalog crate to implement
PgCatalogContextProvider. But that's a compile-time dependency, not a tight coupling issue.

The PgCatalogContextProvider trait itself is already the abstraction - any type can implement it and be passed to setup_pg_catalog(). My extra RoleProvider layer just adds unnecessary indirection.

@sunng87 please tag me to issues that needs to a addressed.

@iPeluwa iPeluwa closed this Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Revisit AuthManager design

2 participants