From 390d460138b66a3dddd4fc6288366c3ddbe0c710 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Mon, 16 May 2005 02:50:58 +0000 Subject: Update Chinese FAQ to xhtml. --- doc/src/FAQ/FAQ_DEV.html | 55 +++++++++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 24 deletions(-) (limited to 'doc/src/FAQ/FAQ_DEV.html') diff --git a/doc/src/FAQ/FAQ_DEV.html b/doc/src/FAQ/FAQ_DEV.html index cc0f8ad142e..9a863498829 100644 --- a/doc/src/FAQ/FAQ_DEV.html +++ b/doc/src/FAQ/FAQ_DEV.html @@ -13,7 +13,7 @@

Developer's Frequently Asked Questions (FAQ) for PostgreSQL

-

Last updated: Fri May 6 13:47:54 EDT 2005

+

Last updated: Sat May 14 12:26:01 EDT 2005

Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -34,8 +34,8 @@ 1.3) What areas need work?
1.4) What do I do after choosing an item to work on?
- 1.5) Where can I learn more about the code?
- 1.6) I've developed a patch, what next?
+ 1.5) I've developed a patch, what next?
+ 1.6) Where can I learn more about the code?
1.7) How do I download/update the current source tree?
1.8) How do I test my changes?
@@ -139,9 +139,13 @@

Send an email to pgsql-hackers with a proposal for what you want to do (assuming your contribution is not trivial). Working in - isolation is not advisable: others may be working on the same TODO - item; you may have misunderstood the TODO item; your approach may - benefit from the review of others.

+ isolation is not advisable because others might be working on the same + TODO item, or you might have misunderstood the TODO item. In the + email, discuss both the internal implementation method you plan to + 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.

A web site is maintained for patches that are ready to be applied, @@ -150,30 +154,33 @@ http://momjian.postgresql.org/cgi-bin/pgpatches2.

-

1.5) Where can I learn more about the - code?

- -

Other than documentation in the source tree itself, you can find - some papers/presentations discussing the code at - http://www.postgresql.org/developer.

- -

1.6) 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 with this, you may find the script + unfamiliar with this, you might find the script src/tools/makediff/difforig useful.

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 + 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 may be - either accepted or sent back for further work.

+ 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.

+ +

1.6) Where can I learn more about the + code?

+ +

Other than documentation in the source tree itself, you can find + some papers/presentations discussing the code at + http://www.postgresql.org/developer.

1.7) How do I download/update the current source tree?

@@ -183,7 +190,7 @@ ftp://ftp.postgresql.org.

-

Regular developers may want to take advantage of anonymous +

Regular developers might want to take advantage of anonymous access to our source code management system. The source tree is currently hosted in CVS. For details of how to obtain the source from CVS see

If you've deliberately changed existing behavior, this change - may cause a regression test failure but not any actual regression. + might cause a regression test failure but not any actual regression. If so, you should also patch the regression test suite.

Other run time testing

@@ -769,7 +776,7 @@ delete tuples by passing the tuple's t_self to heap_destroy(). You use t_self for heap_update() too. Remember, tuples can be either system - cache copies, which may go away after you call + cache copies, which might go away after you call ReleaseSysCache(), or read directly from disk buffers, which go away when you heap_getnext(), heap_endscan, or ReleaseBuffer(), in the heap_fetch() case. Or it may @@ -904,7 +911,7 @@ to create, copy, read, and output those structures (in particular, the files copyfuncs.c and equalfuncs.c. Make sure you add support for your new field to these files. Find any other - places the structure may need code for your new field. mkid + places the structure might need code for your new field. mkid is helpful with this (see 1.9).

2.5) Why do we use palloc() and @@ -969,7 +976,7 @@ symbols, you can use a debugger to see what is happening. Because the backend was not started from postmaster, it is not running in an identical environment and locking/backend interaction - problems may not be duplicated.

+ problems might not be duplicated.

If the postmaster is running, start psql in one window, then find the PID of the postgres -- cgit v1.2.3