Developer's Frequently Asked Questions (FAQ) for PostgreSQL

Last updated:Sat Dec 24 14:29:33 EST2005

Last updated:Wed Mar 1 17:24:48 EST2006

Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)

1.5) I've developed a patch, what next?

Generate the patch in contextual diff format. If you are unfamiliar

with this, you might find the script src/tools/makediff/difforig

useful. Unified diffs are only preferrable if the file changes are

single-line changes and do not rely on the surrounding lines.

Ensure that your patch is generated against the most recent version of

the code. If it is a patch adding new functionality, the most recent

version is CVS HEAD; if it is a bug fix, this will be the most

recently version of the branch which suffers from the bug (for more on

branches in PostgreSQL, see 1.15).

Finally, submit the patch to pgsql-patches@postgresql.org. It will be

reviewed by other contributors to the project and will be either

accepted or sent back for further work. Also, please try to include

documentation changes as part of the patch. If you can't do that, let

us know and we will manually update the documentation when the patch

is applied.

You will need to submit the patch to pgsql-patches@postgresql.org. It

will be reviewed by other contributors to the project and will be

either accepted or sent back for further work. To help ensure your

patch is reviewed and committed in a timely fashion, please try to

make sure your submission conforms to the following guidelines:

1. Ensure that your patch is generated against the most recent

version of the code, which for developers is CVS HEAD. For more on

branches in PostgreSQL, see 1.15.

2. Try to make your patch as readable as possible by following the

project's code-layout conventions. This makes it easier for the

reviewer, and there's no point in trying to layout things

differently than pgindent. Also avoid unnecessary whitespace

changes because they just distract the reviewer, and formatting

changes will be removed by the next run of pgindent.

3. The patch should be generated in contextual diff format (diff -c

and should be applicable from the root directory. If you are

unfamiliar with this, you might find the script

src/tools/makediff/difforig useful. (Unified diffs are only

preferable if the file changes are single-line changes and do not

rely on surrounding lines.)

4. PostgreSQL is licensed under a BSD license, so any submissions

must conform to the BSD license to be included. If you use code

that is available under some other license that is BSD compatible

(eg. public domain) please note that code in your email submission

5. Confirm that your changes can pass the regression tests. If your

changes are port specific, please list the ports you have tested

it on.

6. Provide an implementation overview, preferably in code comments.

Following the surrounding code commenting style is usually a good

approach.

7. New feature patches should also be accompanied by documentation

patches. If you need help checking the SQL standard, see 1.16.

8. If you are adding a new feature, confirm that it has been tested

thoughly. Try to test the feature in all conceivable scenarios.

9. If it is a performance patch, please provide confirming test

results to show the benefit of your patch. It is OK to post

patches without this information, though the patch will not be

applied until somebody has tested the patch and found a

significant performance improvement.

Even if you pass all of the above, the patch might still be rejected

for other reasons. Please be prepared to listen to comments and make

modifications.

You will be notified via email when the patch is applied, and your

name will appear in the next version of the release notes.

1.6) Where can I learn more about the code?

<H1>Developer's Frequently Asked Questions (FAQ) for

PostgreSQL</H1>

<P>Last updated:Sat Dec 24 14:29:33 EST2005</P>

<P>Last updated:Wed Mar 1 17:24:48 EST2006</P>

<P>Current maintainer: Bruce Momjian (<Ahref=

"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>