In PostgreSQL community, the most successful patches follow a pattern sorta like this: * Email the hackers list about intentions, ensure you aren't overlooking

In PostgreSQL community, the most successful patches follow a pattern sorta like this: * Email the hackers list about intentions, ensure you aren't overlooking obvious things. The more core maintainers know and understand what you're doing the more likely you are to be met with critical support. (Hopefully this part is obvious!) * Code patch: Prepare the work surface: clean up, refactor, debug, extend, whatever it takes to facilitate easy integration of upcoming feature patches, but preserves existing functionality. The code is internally pretty clean but not necessarily primed to go the direction you want. * Code patches: Plan diffs for human review and validation: Scope and volume matter! Your additions join existing development; plan to maintain your additions against a moving codebase throughout the integration process.