Hello Maintainers,
I've been evaluating the r2dbc-postgresql driver for a project that requires reactive database connectivity. Our target database is KingbaseES, which is a database engine heavily derived from and highly compatible with PostgreSQL (specifically utilizing the PostgreSQL Frontend/Backend Protocol V3).
During our preliminary testing, we found that basic connectivity works flawlessly using this driver. However, KingbaseES introduces certain specific authentication algorithms (e.g., national cryptographic standards) and a few proprietary data types/OIDs that diverge from standard PostgreSQL.
I am considering dedicating engineering time over the next few months to implement support for these KingbaseES-specific features. Before I begin writing any code or preparing a Pull Request, I wanted to reach out to the core team to understand the project's stance on this:
Scope Acceptability: Is the r2dbc-postgresql community open to accepting PRs that add support for PostgreSQL-derived databases (like KingbaseES, or similar forks), provided the changes do not affect standard Postgres users?
Architecture Preference: If acceptable, what is the preferred architectural approach? Would you prefer a plugin/SPI mechanism where these specific authenticators and codecs can be registered externally, or a direct (but isolated) addition within the driver's core modules?
My goal is to ensure any contribution aligns perfectly with your roadmap and maintains the strict performance and stability standards of this driver. If the community feels this is outside the scope of r2dbc-postgresql, I completely understand and will pursue an independent fork.
Thank you for your time and for maintaining this excellent project.
Best regards,
Hello Maintainers,
I've been evaluating the r2dbc-postgresql driver for a project that requires reactive database connectivity. Our target database is KingbaseES, which is a database engine heavily derived from and highly compatible with PostgreSQL (specifically utilizing the PostgreSQL Frontend/Backend Protocol V3).
During our preliminary testing, we found that basic connectivity works flawlessly using this driver. However, KingbaseES introduces certain specific authentication algorithms (e.g., national cryptographic standards) and a few proprietary data types/OIDs that diverge from standard PostgreSQL.
I am considering dedicating engineering time over the next few months to implement support for these KingbaseES-specific features. Before I begin writing any code or preparing a Pull Request, I wanted to reach out to the core team to understand the project's stance on this:
Scope Acceptability: Is the r2dbc-postgresql community open to accepting PRs that add support for PostgreSQL-derived databases (like KingbaseES, or similar forks), provided the changes do not affect standard Postgres users?
Architecture Preference: If acceptable, what is the preferred architectural approach? Would you prefer a plugin/SPI mechanism where these specific authenticators and codecs can be registered externally, or a direct (but isolated) addition within the driver's core modules?
My goal is to ensure any contribution aligns perfectly with your roadmap and maintains the strict performance and stability standards of this driver. If the community feels this is outside the scope of r2dbc-postgresql, I completely understand and will pursue an independent fork.
Thank you for your time and for maintaining this excellent project.
Best regards,