use, and any user-visible changes (new syntax, etc). For complex
patches, it is important to get community feeback on your proposal
before starting work. Failure to do so might mean your patch is
- rejected.
+ rejected. If your work is being sponsored by a company, read this
+ article for tips on being more effective.
A web site is maintained for patches awaiting review,
those that are being kept for the next release,
http://momjian.postgresql.org/cgi-bin/pgpatches_hold.
-
+
1.5) I've developed a patch, what next?
src/tools/make_diff/difforig useful. (Unified diffs are only
preferable if the file changes are single-line changes and do not
rely on surrounding lines.)
-
+
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
We try to build on as many different canonical distributions as we can.
Currently we are able to build on Red Hat Linux 9, RHEL 3 and above,
and all Fedora Core Linux releases.
-
+
To test the binaries, we install them on our local machines and run
regression tests. If the package builders uses postgres user to build the
rpms, then it is possible to run regression tests during RPM builds.
is possible. Only the standard released 'official to that release'
compiler is used -- and only the standard official kernel is used as
well.
-
+
PGDG RPM Building Project does not build RPMs for Mandrake .
We usually have only one SRPM for all platforms. This is because of our
limited resources. However, on some cases, we may distribute different
SRPMs for different platforms, depending on possible compilation problems,
especially on older distros.
-
+
Please note that this is a volunteered job -- We are doing our best to
keep packages up to date. We, at least, provide SRPMs for all platforms.
For example, if you do not find a RHEL 4 x86_64 RPM in our FTP site, it
List *list;
ListCell *i;
-
+
foreach(i, list)
{
Var *var = lfirst(i);