Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
8fe61f0d
Commit
8fe61f0d
authored
Mar 01, 2006
by
Bruce Momjian
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update text file.
parent
711c3839
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
48 additions
and
19 deletions
+48
-19
doc/FAQ_DEV
doc/FAQ_DEV
+47
-18
doc/src/FAQ/FAQ_DEV.html
doc/src/FAQ/FAQ_DEV.html
+1
-1
No files found.
doc/FAQ_DEV
View file @
8fe61f0d
Developer's Frequently Asked Questions (FAQ) for PostgreSQL
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)
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
...
@@ -108,23 +108,52 @@ General Questions
...
@@ -108,23 +108,52 @@ General Questions
1.5) I've developed a patch, what next?
1.5) I've developed a patch, what next?
Generate the patch in contextual diff format. If you are unfamiliar
You will need to submit the patch to pgsql-patches@postgresql.org. It
with this, you might find the script src/tools/makediff/difforig
will be reviewed by other contributors to the project and will be
useful. Unified diffs are only preferrable if the file changes are
either accepted or sent back for further work. To help ensure your
single-line changes and do not rely on the surrounding lines.
patch is reviewed and committed in a timely fashion, please try to
make sure your submission conforms to the following guidelines:
Ensure that your patch is generated against the most recent version of
1. Ensure that your patch is generated against the most recent
the code. If it is a patch adding new functionality, the most recent
version of the code, which for developers is CVS HEAD. For more on
version is CVS HEAD; if it is a bug fix, this will be the most
branches in PostgreSQL, see 1.15.
recently version of the branch which suffers from the bug (for more on
2. Try to make your patch as readable as possible by following the
branches in PostgreSQL, see 1.15).
project's code-layout conventions. This makes it easier for the
reviewer, and there's no point in trying to layout things
Finally, submit the patch to pgsql-patches@postgresql.org. It will be
differently than pgindent. Also avoid unnecessary whitespace
reviewed by other contributors to the project and will be either
changes because they just distract the reviewer, and formatting
accepted or sent back for further work. Also, please try to include
changes will be removed by the next run of pgindent.
documentation changes as part of the patch. If you can't do that, let
3. The patch should be generated in contextual diff format (diff -c
us know and we will manually update the documentation when the patch
and should be applicable from the root directory. If you are
is applied.
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?
1.6) Where can I learn more about the code?
...
...
doc/src/FAQ/FAQ_DEV.html
View file @
8fe61f0d
...
@@ -13,7 +13,7 @@
...
@@ -13,7 +13,7 @@
<H1>
Developer's Frequently Asked Questions (FAQ) for
<H1>
Developer's Frequently Asked Questions (FAQ) for
PostgreSQL
</H1>
PostgreSQL
</H1>
<P>
Last updated:
Sat Dec 24 14:29:33 EST 2005
</P>
<P>
Last updated:
Wed Mar 1 17:24:48 EST 2006
</P>
<P>
Current maintainer: Bruce Momjian (
<A
href=
<P>
Current maintainer: Bruce Momjian (
<A
href=
"mailto:pgman@candle.pha.pa.us"
>
pgman@candle.pha.pa.us
</A>
)
<BR>
"mailto:pgman@candle.pha.pa.us"
>
pgman@candle.pha.pa.us
</A>
)
<BR>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment