Check and discuss
Search existing issues, then open one before substantial implementation work.
HOW TO CONTRIBUTE
Turn what you found into a useful change.
Keep the architecture clear
Put code in the right project and avoid breaking existing public APIs.
Add the right tests
Add fast tests and, when needed, prove the behavior against a real PostgreSQL server.
Update the supporting material
Keep examples, documentation, API records, and compatibility notes up to date.
WHERE WORK HELPS
Choose an area where your experience helps.
Each area links to working code, tests, documentation, and planned improvements.
PostgreSQL behavior
Reproduce a connection, type, pooling, login, or data-handling problem.
Explore providerSpecialized packages
Add support for a PostgreSQL extension in ADO.NET, EF Core, and live tests.
Explore extensionsOperational workloads
Test initial loads, replay, destination recovery, or long-running workloads.
Explore real timeExecutable scenarios
Turn a real application pattern into a clear, maintainable example project.
Read guidesWHAT A GOOD CHANGE INCLUDES
Show that the change works.
Keep the architecture clear, protect existing APIs, follow PostgreSQL behavior, and add tests that match the risk of the change.
PostgreSQL is the specificationPostgreSQL behavior and its official documentation decide what is correct.
Public API changes are deliberateAPI records and compatibility guidance must be updated with intentional public changes.
Tests match the riskChoose unit, live, security, load, or long-running tests based on what could go wrong.
Secrets never enter the repositoryEnvironment variables and isolated test infrastructure carry credentials.
VULNERABILITY REPORTING
Report security issues privately.
Do not open a public issue for a suspected vulnerability. Follow the repository security policy and contact the maintainers privately through the repository hosting platform. No unverified email or community channel is advertised.