|
|
|
|
@ -1,7 +1,7 @@ |
|
|
|
|
|
|
|
|
|
Developer's Frequently Asked Questions (FAQ) for PostgreSQL |
|
|
|
|
|
|
|
|
|
Last updated: Sat Dec 24 14:29:33 EST 2005 |
|
|
|
|
Last updated: Wed Mar 1 17:24:48 EST 2006 |
|
|
|
|
|
|
|
|
|
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) |
|
|
|
|
|
|
|
|
|
@ -108,23 +108,52 @@ General Questions |
|
|
|
|
|
|
|
|
|
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? |
|
|
|
|
|
|
|
|
|
|
Bruce Momjian
20 years ago