|
1 | 1 |
|
2 | 2 | Developer's Frequently Asked Questions (FAQ) for PostgreSQL
|
3 | 3 |
|
4 |
| - Last updated: Tue Feb 27 18:12:31 EST 2007 |
| 4 | + Last updated: Wed Feb 28 12:27:44 EST 2007 |
5 | 5 |
|
6 | 6 | Current maintainer: Bruce Momjian ( [email protected])
|
7 | 7 |
|
@@ -136,20 +136,22 @@ General Questions
|
136 | 136 | src/tools/make_diff/difforig useful. (Unified diffs are only
|
137 | 137 | preferable if the file changes are single-line changes and do not
|
138 | 138 | rely on surrounding lines.)
|
139 |
| - 4. PostgreSQL is licensed under a BSD license, so any submissions |
140 |
| - must conform to the BSD license to be included. If you use code |
141 |
| - that is available under some other license that is BSD compatible |
142 |
| - (eg. public domain) please note that code in your email submission |
| 139 | + 4. PostgreSQL is licensed under a BSD license. By posting a patch to |
| 140 | + the public PostgreSQL mailling lists, you are giving the |
| 141 | + PostgreSQL Global Development Group the non-revokable right to |
| 142 | + distribute your patch under the BSD license. If you use code that |
| 143 | + is available under some other license that is BSD compatible (eg. |
| 144 | + public domain), please note that in your email submission. |
143 | 145 | 5. Confirm that your changes can pass the regression tests. If your
|
144 | 146 | changes are port specific, please list the ports you have tested
|
145 | 147 | it on.
|
146 |
| - 6. Provide an implementation overview, preferably in code comments. |
147 |
| - Following the surrounding code commenting style is usually a good |
148 |
| - approach. |
| 148 | + 6. If you are adding a new feature, confirm that it has been tested |
| 149 | + thoroughly. Try to test the feature in all conceivable scenarios. |
149 | 150 | 7. New feature patches should also be accompanied by documentation
|
150 | 151 | patches. If you need help checking the SQL standard, see 1.16.
|
151 |
| - 8. If you are adding a new feature, confirm that it has been tested |
152 |
| - thoroughly. Try to test the feature in all conceivable scenarios. |
| 152 | + 8. Provide an implementation overview, preferably in code comments. |
| 153 | + Following the surrounding code commenting style is usually a good |
| 154 | + approach. |
153 | 155 | 9. If it is a performance patch, please provide confirming test
|
154 | 156 | results to show the benefit of your patch. It is OK to post
|
155 | 157 | patches without this information, though the patch will not be
|
|
0 commit comments