mirror of
				https://github.com/postgres/postgres.git
				synced 2025-10-29 22:49:41 +03:00 
			
		
		
		
	Update FAQ_DEV.
This commit is contained in:
		
							
								
								
									
										86
									
								
								doc/FAQ_DEV
									
									
									
									
									
								
							
							
						
						
									
										86
									
								
								doc/FAQ_DEV
									
									
									
									
									
								
							| @@ -27,6 +27,7 @@ | |||||||
|    11) What is configure all about? |    11) What is configure all about? | ||||||
|    12) How do I add a new port? |    12) How do I add a new port? | ||||||
|    13) What is CommandCounterIncrement()? |    13) What is CommandCounterIncrement()? | ||||||
|  |    13) Why don't we use threads in the backend? | ||||||
|      _________________________________________________________________ |      _________________________________________________________________ | ||||||
|     |     | ||||||
|   1) What tools are available for developers? |   1) What tools are available for developers? | ||||||
| @@ -36,8 +37,7 @@ | |||||||
|    /tools directory are designed for developers. |    /tools directory are designed for developers. | ||||||
|     RELEASE_CHANGES     changes we have to make for each release |     RELEASE_CHANGES     changes we have to make for each release | ||||||
|     SQL_keywords        standard SQL'92 keywords |     SQL_keywords        standard SQL'92 keywords | ||||||
|         backend                 description/flowchart of the backend directorie |     backend         description/flowchart of the backend directories | ||||||
| s |  | ||||||
|     ccsym           find standard defines made by your compiler |     ccsym           find standard defines made by your compiler | ||||||
|     entab           converts tabs to spaces, used by pgindent |     entab           converts tabs to spaces, used by pgindent | ||||||
|     find_static     finds functions that could be made static |     find_static     finds functions that could be made static | ||||||
| @@ -95,7 +95,7 @@ s | |||||||
|     emacs: |     emacs: | ||||||
|         M-x set-variable tab-width |         M-x set-variable tab-width | ||||||
|         or |         or | ||||||
|                 ; Cmd to set tab stops &etc for working with PostgreSQL code |         ; Cmd to set tab stops & indenting for working with PostgreSQL code | ||||||
|              (c-add-style "pgsql" |              (c-add-style "pgsql" | ||||||
|                       '("bsd" |                       '("bsd" | ||||||
|                                  (indent-tabs-mode . t) |                                  (indent-tabs-mode . t) | ||||||
| @@ -108,8 +108,7 @@ s | |||||||
|         and add this to your autoload list (modify file path in macro): |         and add this to your autoload list (modify file path in macro): | ||||||
|  |  | ||||||
|         (setq auto-mode-alist |         (setq auto-mode-alist | ||||||
|                       (cons '("\\`/usr/local/src/pgsql/.*\\.[chyl]\\'" . pgsql- |               (cons '("\\`/usr/local/src/pgsql/.*\\.[chyl]\\'" . pgsql-c-mode) | ||||||
| c-mode) |  | ||||||
|             auto-mode-alist)) |             auto-mode-alist)) | ||||||
|         or |         or | ||||||
|             /* |             /* | ||||||
| @@ -174,8 +173,7 @@ c-mode) | |||||||
|           a typical code snipped that loops through a List containing Var |           a typical code snipped that loops through a List containing Var | ||||||
|           *'s and processes each one: |           *'s and processes each one: | ||||||
|            |            | ||||||
|  | List *i, *list; | ||||||
|     List *i, *list; |  | ||||||
|  |  | ||||||
|     foreach(i, list) |     foreach(i, list) | ||||||
|     { |     { | ||||||
| @@ -207,16 +205,14 @@ c-mode) | |||||||
|            |            | ||||||
|    You can print nodes easily inside gdb. First, to disable output |    You can print nodes easily inside gdb. First, to disable output | ||||||
|    truncation when you use the gdb print command: |    truncation when you use the gdb print command: | ||||||
|  | (gdb) set print elements 0 | ||||||
|         (gdb) set print elements 0 |  | ||||||
|  |  | ||||||
|    Instead of printing values in gdb format, you can use the next two |    Instead of printing values in gdb format, you can use the next two | ||||||
|    commands to print out List, Node, and structure contents in a verbose |    commands to print out List, Node, and structure contents in a verbose | ||||||
|    format that is easier to understand. List's are unrolled into nodes, |    format that is easier to understand. List's are unrolled into nodes, | ||||||
|    and nodes are printed in detail. The first prints in a short format, |    and nodes are printed in detail. The first prints in a short format, | ||||||
|    and the second in a long format: |    and the second in a long format: | ||||||
|  | (gdb) call print(any_pointer) | ||||||
|         (gdb) call print(any_pointer) |  | ||||||
|     (gdb) call pprint(any_pointer) |     (gdb) call pprint(any_pointer) | ||||||
|  |  | ||||||
|    The output appears in the postmaster log file, or on your screen if |    The output appears in the postmaster log file, or on your screen if | ||||||
| @@ -292,7 +288,7 @@ c-mode) | |||||||
|    tables in columns of type Name. Name is a fixed-length, |    tables in columns of type Name. Name is a fixed-length, | ||||||
|    null-terminated type of NAMEDATALEN bytes. (The default value for |    null-terminated type of NAMEDATALEN bytes. (The default value for | ||||||
|    NAMEDATALEN is 32 bytes.) |    NAMEDATALEN is 32 bytes.) | ||||||
|         typedef struct nameData | typedef struct nameData | ||||||
|     { |     { | ||||||
|         char        data[NAMEDATALEN]; |         char        data[NAMEDATALEN]; | ||||||
|     } NameData; |     } NameData; | ||||||
| @@ -311,8 +307,8 @@ c-mode) | |||||||
|   9) How do I efficiently access information in tables from the backend code? |   9) How do I efficiently access information in tables from the backend code? | ||||||
|    |    | ||||||
|    You first need to find the tuples(rows) you are interested in. There |    You first need to find the tuples(rows) you are interested in. There | ||||||
|    are two ways. First, SearchSysCache() and related functions allow |    are two ways. First, SearchSysCache() and related functions allow you | ||||||
|    you to query the system catalogs. This is the preferred way to access |    to query the system catalogs. This is the preferred way to access | ||||||
|    system tables, because the first call to the cache loads the needed |    system tables, because the first call to the cache loads the needed | ||||||
|    rows, and future requests can return the results without accessing the |    rows, and future requests can return the results without accessing the | ||||||
|    base table. The caches use system table indexes to look up tuples. A |    base table. The caches use system table indexes to look up tuples. A | ||||||
| @@ -321,13 +317,14 @@ c-mode) | |||||||
|    src/backend/utils/cache/lsyscache.c contains many column-specific |    src/backend/utils/cache/lsyscache.c contains many column-specific | ||||||
|    cache lookup functions. |    cache lookup functions. | ||||||
|     |     | ||||||
|    The rows returned are cache-owned versions of the heap rows.  Therefore, |    The rows returned are cache-owned versions of the heap rows. | ||||||
|    you must not modify or delete the tuple returned by SearchSysCache(). |    Therefore, you must not modify or delete the tuple returned by | ||||||
|    What you *should* do is release it with ReleaseSysCache() when you are |    SearchSysCache(). What you should do is release it with | ||||||
|    done using it; this informs the cache that it can discard that tuple |    ReleaseSysCache() when you are done using it; this informs the cache | ||||||
|    if necessary.  If you neglect to call ReleaseSysCache(), then the cache |    that it can discard that tuple if necessary. If you neglect to call | ||||||
|    entry will remain locked in the cache until end of transaction, which is |    ReleaseSysCache(), then the cache entry will remain locked in the | ||||||
|    tolerable but not very desirable. |    cache until end of transaction, which is tolerable but not very | ||||||
|  |    desirable. | ||||||
|     |     | ||||||
|    If you can't use the system cache, you will need to retrieve the data |    If you can't use the system cache, you will need to retrieve the data | ||||||
|    directly from the heap table, using the buffer cache that is shared by |    directly from the heap table, using the buffer cache that is shared by | ||||||
| @@ -345,27 +342,25 @@ c-mode) | |||||||
|    heap_fetch(), you must pass a Buffer pointer, and ReleaseBuffer() it |    heap_fetch(), you must pass a Buffer pointer, and ReleaseBuffer() it | ||||||
|    when completed. |    when completed. | ||||||
|     |     | ||||||
|    Once you have the row, you can get data that is common |    Once you have the row, you can get data that is common to all tuples, | ||||||
|    to all tuples, like t_self and t_oid, by merely accessing the |    like t_self and t_oid, by merely accessing the HeapTuple structure | ||||||
|    HeapTuple structure entries. If you need a table-specific column, you |    entries. If you need a table-specific column, you should take the | ||||||
|    should take the HeapTuple pointer, and use the GETSTRUCT() macro to |    HeapTuple pointer, and use the GETSTRUCT() macro to access the | ||||||
|    access the table-specific start of the tuple. You then cast the |    table-specific start of the tuple. You then cast the pointer as a | ||||||
|    pointer as a Form_pg_proc pointer if you are accessing the pg_proc |    Form_pg_proc pointer if you are accessing the pg_proc table, or | ||||||
|    table, or Form_pg_type if you are accessing pg_type. You can then |    Form_pg_type if you are accessing pg_type. You can then access the | ||||||
|    access the columns by using a structure pointer: |    columns by using a structure pointer: | ||||||
|  | ((Form_pg_class) GETSTRUCT(tuple))->relnatts | ||||||
|  |  | ||||||
|         ((Form_pg_class) GETSTRUCT(tuple))->relnatts |    You must not directly change live tuples in this way. The best way is | ||||||
|  |    to use heap_modifytuple() and pass it your original tuple, and the | ||||||
|    You must not directly change live tuples in this way. The best way |    values you want changed. It returns a palloc'ed tuple, which you pass | ||||||
|    is to use heap_modifytuple() and pass it your original tuple, and the |    to heap_replace(). You can delete tuples by passing the tuple's t_self | ||||||
|    values you want changed. It returns a palloc'ed tuple, which you |    to heap_destroy(). You use t_self for heap_update() too. Remember, | ||||||
|    pass to heap_replace(). You can delete tuples by passing the tuple's |    tuples can be either system cache copies, which may go away after you | ||||||
|    t_self to heap_destroy(). You use t_self for heap_update() too. |    call ReleaseSysCache(), or read directly from disk buffers, which go | ||||||
|  |    away when you heap_getnext(), heap_endscan, or ReleaseBuffer(), in the | ||||||
|    Remember, tuples can be either system cache copies, which may go away |    heap_fetch() case. Or it may be a palloc'ed tuple, that you must | ||||||
|    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 be a palloc'ed tuple, that you must |  | ||||||
|    pfree() when finished. |    pfree() when finished. | ||||||
|     |     | ||||||
|   10) What is elog()? |   10) What is elog()? | ||||||
| @@ -429,3 +424,12 @@ c-mode) | |||||||
|    to be broken into pieces so each piece can see rows modified by |    to be broken into pieces so each piece can see rows modified by | ||||||
|    previous pieces. CommandCounterIncrement() increments the Command |    previous pieces. CommandCounterIncrement() increments the Command | ||||||
|    Counter, creating a new part of the transaction. |    Counter, creating a new part of the transaction. | ||||||
|  |     | ||||||
|  |   14) Why don't we use threads in the backend? | ||||||
|  |    | ||||||
|  |    There are several reasons threads are not used: | ||||||
|  |      * Historically, threads were unsupported and buggy. | ||||||
|  |      * An error in one backend can corrupt other backends. | ||||||
|  |      * Speed improvements using threads are small compared to the | ||||||
|  |        remaining backend startup time. | ||||||
|  |      * The backend code would be more complex. | ||||||
|   | |||||||
| @@ -1,54 +1,66 @@ | |||||||
|  | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"> | ||||||
|  |  | ||||||
| <HTML> | <HTML> | ||||||
| <HEAD> |   <HEAD> | ||||||
| <TITLE>PostgreSQL Developers FAQ</title> |     <META name="generator" content="HTML Tidy, see www.w3.org"> | ||||||
| </HEAD> |  | ||||||
| <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF"> |  | ||||||
| <H1> |  | ||||||
| Developer's Frequently Asked Questions (FAQ) for PostgreSQL |  | ||||||
| </H1> |  | ||||||
| <P> |  | ||||||
| Last updated:		Fri Jun  9 21:54:54 EDT 2000 |  | ||||||
| <P> |  | ||||||
| Current maintainer:	Bruce Momjian (<a |  | ||||||
| href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<BR> |  | ||||||
| <P> |  | ||||||
| The most recent version of this document can be viewed at |  | ||||||
| the postgreSQL Web site, <a |  | ||||||
| href="http://PostgreSQL.org">http://PostgreSQL.org</a>. |  | ||||||
| <P> |  | ||||||
| <HR> |  | ||||||
| <P> |  | ||||||
|  |  | ||||||
| <CENTER><H2>Questions</H2></CENTER> |     <TITLE>PostgreSQL Developers FAQ</TITLE> | ||||||
| <a href="#1">1</a>)	What tools are available for developers?<BR> |   </HEAD> | ||||||
| <a href="#2">2</a>)	What books are good for developers?<BR> |  | ||||||
| <a href="#3">3</a>)	Why do we use <I>palloc</I>() and <I>pfree</I>() to allocate memory?<BR> |  | ||||||
| <a href="#4">4</a>)	Why do we use <I>Node</I> and <I>List</I> to |  | ||||||
| make data structures?<BR> |  | ||||||
| <a href="#5">5</a>)	How do I add a feature or fix a bug?<BR> |  | ||||||
| <a href="#6">6</a>)	How do I download/update the current source tree?<BR> |  | ||||||
| <a href="#7">7</a>)	How do I test my changes?<BR> |  | ||||||
| <a href="#7">7</a>)	I just added a field to a structure.  What else |  | ||||||
| should I do?<BR> |  | ||||||
| <a href="#8">8</a>)	Why are table, column, type, function, view |  | ||||||
| names sometimes referenced as <I>Name</I> or <I>NameData,</I> and |  | ||||||
| sometimes as <I>char *?</I><BR> |  | ||||||
| <a href="#9">9</a>)	How do I efficiently access information in |  | ||||||
| tables from the backend code?<BR> |  | ||||||
| <a href="#10">10</a>)	What is elog()?<BR> |  | ||||||
| <a href="#11">11</a>)	What is configure all about?<BR> |  | ||||||
| <a href="#12">12</a>)	How do I add a new port?<BR> |  | ||||||
| <a href="#13">13</a>)	What is CommandCounterIncrement()?<BR> |  | ||||||
| <BR> |  | ||||||
| <HR> |  | ||||||
|  |  | ||||||
| <H3><a |   <BODY bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" | ||||||
| name="1">1</a>)	What tools are available for developers?</H3><P> |   alink="#0000FF"> | ||||||
|  |     <H1>Developer's Frequently Asked Questions (FAQ) for | ||||||
|  |     PostgreSQL</H1> | ||||||
|  |  | ||||||
| Aside from the User documentation mentioned in the regular FAQ, there |     <P>Last updated: Fri Jun 9 21:54:54 EDT 2000</P> | ||||||
| are several development tools available.  First, all the files in the |  | ||||||
| <I>/tools</I> directory are designed for developers. |  | ||||||
|  |  | ||||||
|  |     <P>Current maintainer: Bruce Momjian (<A href= | ||||||
|  |     "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> | ||||||
|  |     </P> | ||||||
|  |  | ||||||
|  |     <P>The most recent version of this document can be viewed at the | ||||||
|  |     postgreSQL Web site, <A href= | ||||||
|  |     "http://PostgreSQL.org">http://PostgreSQL.org</A>.<BR> | ||||||
|  |     </P> | ||||||
|  |     <HR> | ||||||
|  |     <BR> | ||||||
|  |       | ||||||
|  |  | ||||||
|  |     <CENTER> | ||||||
|  |       <H2>Questions</H2> | ||||||
|  |     </CENTER> | ||||||
|  |     <A href="#1">1</A>) What tools are available for developers?<BR> | ||||||
|  |      <A href="#2">2</A>) What books are good for developers?<BR> | ||||||
|  |      <A href="#3">3</A>) Why do we use <I>palloc</I>() and | ||||||
|  |     <I>pfree</I>() to allocate memory?<BR> | ||||||
|  |      <A href="#4">4</A>) Why do we use <I>Node</I> and <I>List</I> to | ||||||
|  |     make data structures?<BR> | ||||||
|  |      <A href="#5">5</A>) How do I add a feature or fix a bug?<BR> | ||||||
|  |      <A href="#6">6</A>) How do I download/update the current source | ||||||
|  |     tree?<BR> | ||||||
|  |      <A href="#7">7</A>) How do I test my changes?<BR> | ||||||
|  |      <A href="#7">7</A>) I just added a field to a structure. What else | ||||||
|  |     should I do?<BR> | ||||||
|  |      <A href="#8">8</A>) Why are table, column, type, function, view | ||||||
|  |     names sometimes referenced as <I>Name</I> or <I>NameData,</I> and | ||||||
|  |     sometimes as <I>char *?</I><BR> | ||||||
|  |      <A href="#9">9</A>) How do I efficiently access information in | ||||||
|  |     tables from the backend code?<BR> | ||||||
|  |      <A href="#10">10</A>) What is elog()?<BR> | ||||||
|  |      <A href="#11">11</A>) What is configure all about?<BR> | ||||||
|  |      <A href="#12">12</A>) How do I add a new port?<BR> | ||||||
|  |      <A href="#13">13</A>) What is CommandCounterIncrement()?<BR> | ||||||
|  |      <A href="#14">13</A>) Why don't we use threads in the backend?<BR> | ||||||
|  |      <BR> | ||||||
|  |       | ||||||
|  |     <HR> | ||||||
|  |  | ||||||
|  |     <H3><A name="1">1</A>) What tools are available for | ||||||
|  |     developers?</H3> | ||||||
|  |  | ||||||
|  |     <P>Aside from the User documentation mentioned in the regular FAQ, | ||||||
|  |     there are several development tools available. First, all the files | ||||||
|  |     in the <I>/tools</I> directory are designed for developers.</P> | ||||||
| <PRE> | <PRE> | ||||||
|     RELEASE_CHANGES     changes we have to make for each release |     RELEASE_CHANGES     changes we have to make for each release | ||||||
|     SQL_keywords        standard SQL'92 keywords |     SQL_keywords        standard SQL'92 keywords | ||||||
| @@ -67,47 +79,45 @@ are several development tools available.  First, all the files in the | |||||||
|     pginclude       scripts for adding/removing include files |     pginclude       scripts for adding/removing include files | ||||||
|     unused_oids     in pgsql/src/include/catalog |     unused_oids     in pgsql/src/include/catalog | ||||||
| </PRE> | </PRE> | ||||||
|  |     Let me note some of these. If you point your browser at the | ||||||
|  |     <I>file:/usr/local/src/pgsql/src/tools/backend/index.html</I> | ||||||
|  |     directory, you will see few paragraphs describing the data flow, | ||||||
|  |     the backend components in a flow chart, and a description of the | ||||||
|  |     shared memory area. You can click on any flowchart box to see a | ||||||
|  |     description. If you then click on the directory name, you will be | ||||||
|  |     taken to the source directory, to browse the actual source code | ||||||
|  |     behind it. We also have several README files in some source | ||||||
|  |     directories to describe the function of the module. The browser | ||||||
|  |     will display these when you enter the directory also. The | ||||||
|  |     <I>tools/backend</I> directory is also contained on our web page | ||||||
|  |     under the title <I>How PostgreSQL Processes a Query.</I>  | ||||||
|  |  | ||||||
| Let me note some of these.  If you point your browser at the |     <P>Second, you really should have an editor that can handle tags, | ||||||
| <I>file:/usr/local/src/pgsql/src/tools/backend/index.html</I> directory, |     so you can tag a function call to see the function definition, and | ||||||
| you will see few paragraphs describing the data flow, the backend |     then tag inside that function to see an even lower-level function, | ||||||
| components in a flow chart, and a description of the shared memory area. |     and then back out twice to return to the original function. Most | ||||||
| You can click on any flowchart box to see a description.  If you then |     editors support this via <I>tags</I> or <I>etags</I> files.</P> | ||||||
| click on the directory name, you will be taken to the source directory, |  | ||||||
| to browse the actual source code behind it. We also have several README |  | ||||||
| files in some source directories to describe the function of the module. |  | ||||||
|  The browser will display these when you enter the directory also.  The |  | ||||||
| <I>tools/backend</I> directory is also contained on our web page under |  | ||||||
| the title <I>How PostgreSQL Processes a Query.</I><P> |  | ||||||
|  |  | ||||||
|  |     <P>Third, you need to get <I>id-utils</I> from:</P> | ||||||
|  | <PRE> | ||||||
|  |     <A href= | ||||||
|  | "ftp://alpha.gnu.org/gnu/id-utils-3.2d.tar.gz">ftp://alpha.gnu.org/gnu/id-utils-3.2d.tar.gz</A> | ||||||
|  |     <A href= | ||||||
|  | "ftp://tug.org/gnu/id-utils-3.2d.tar.gz">ftp://tug.org/gnu/id-utils-3.2d.tar.gz</A> | ||||||
|  |     <A href= | ||||||
|  | "ftp://ftp.enst.fr/pub/gnu/gnits/id-utils-3.2d.tar.gz">ftp://ftp.enst.fr/pub/gnu/gnits/id-utils-3.2d.tar.gz</A> | ||||||
|  | </PRE> | ||||||
|  |     By running <I>tools/make_mkid</I>, an archive of source symbols can | ||||||
|  |     be created that can be rapidly queried like <I>grep</I> or edited. | ||||||
|  |     Others prefer <I>glimpse.</I>  | ||||||
|  |  | ||||||
| Second, you really should have an editor that can handle tags, so you |     <P><I>make_diff</I> has tools to create patch diff files that can | ||||||
| can tag a function call to see the function definition, and then tag |     be applied to the distribution.</P> | ||||||
| inside that function to see an even lower-level function, and then back |  | ||||||
| out twice to return to the original function.  Most editors support this |  | ||||||
| via <I>tags</I> or <I>etags</I> files.<P> |  | ||||||
|  |  | ||||||
|  |     <P>Our standard format is to indent each code level with one tab, | ||||||
| Third, you need to get <I>id-utils</I> from: |     where each tab is four spaces. You will need to set your editor to | ||||||
| <pre> |     display tabs as four spaces:<BR> | ||||||
| 	<a href="ftp://alpha.gnu.org/gnu/id-utils-3.2d.tar.gz">ftp://alpha.gnu.org/gnu/id-utils-3.2d.tar.gz</a> |     </P> | ||||||
| 	<a href="ftp://tug.org/gnu/id-utils-3.2d.tar.gz">ftp://tug.org/gnu/id-utils-3.2d.tar.gz</a> |  | ||||||
| 	<a href="ftp://ftp.enst.fr/pub/gnu/gnits/id-utils-3.2d.tar.gz">ftp://ftp.enst.fr/pub/gnu/gnits/id-utils-3.2d.tar.gz</a> |  | ||||||
| </pre> |  | ||||||
|  |  | ||||||
| By running <I>tools/make_mkid</I>, an archive of source symbols can be |  | ||||||
| created that can be rapidly queried like <I>grep</I> or edited.  Others |  | ||||||
| prefer <I>glimpse.</I><P> |  | ||||||
|  |  | ||||||
|  |  | ||||||
| <I>make_diff</I> has tools to create patch diff files that can be |  | ||||||
| applied to the distribution.<P> |  | ||||||
|  |  | ||||||
|  |  | ||||||
| Our standard format is to indent each code level with one tab, where |  | ||||||
| each tab is four spaces.  You will need to set your editor to display |  | ||||||
| tabs as four spaces: |  | ||||||
| <BR> |  | ||||||
| <PRE> | <PRE> | ||||||
|     vi in ~/.exrc: |     vi in ~/.exrc: | ||||||
|             set tabstop=4 |             set tabstop=4 | ||||||
| @@ -119,7 +129,7 @@ tabs as four spaces: | |||||||
|     emacs: |     emacs: | ||||||
|         M-x set-variable tab-width |         M-x set-variable tab-width | ||||||
|         or |         or | ||||||
| 		; Cmd to set tab stops &etc for working with PostgreSQL code |         ; Cmd to set tab stops & indenting for working with PostgreSQL code | ||||||
|              (c-add-style "pgsql" |              (c-add-style "pgsql" | ||||||
|                       '("bsd" |                       '("bsd" | ||||||
|                                  (indent-tabs-mode . t) |                                  (indent-tabs-mode . t) | ||||||
| @@ -143,71 +153,77 @@ tabs as four spaces: | |||||||
|              * End: |              * End: | ||||||
|              */ |              */ | ||||||
| </PRE> | </PRE> | ||||||
| <BR> |     <BR> | ||||||
| <I>pgindent</I> will the format code by specifying |      <I>pgindent</I> will the format code by specifying flags to your | ||||||
| flags to your operating system's utility <I>indent.</I><P>  |     operating system's utility <I>indent.</I>  | ||||||
| <I>pgindent</I> is run on all source files just before each beta test |  | ||||||
| period.  It auto-formats all source files to make them consistent.  |  | ||||||
| Comment blocks that need specific line breaks should be formatted as |  | ||||||
| <I>block comments,</I> where the comment starts as |  | ||||||
| <CODE>/*------</CODE>.  These comments will not be reformatted in any |  | ||||||
| way. |  | ||||||
|  |  | ||||||
| <I>pginclude</I> contains scripts used to add needed #include's to |     <P><I>pgindent</I> is run on all source files just before each beta | ||||||
| include files, and removed unneeded #include's. |     test period. It auto-formats all source files to make them | ||||||
|  |     consistent. Comment blocks that need specific line breaks should be | ||||||
|  |     formatted as <I>block comments,</I> where the comment starts as | ||||||
|  |     <CODE>/*------</CODE>. These comments will not be reformatted in | ||||||
|  |     any way. <I>pginclude</I> contains scripts used to add needed | ||||||
|  |     #include's to include files, and removed unneeded #include's. When | ||||||
|  |     adding system types, you will need to assign oids to them. There is | ||||||
|  |     also a script called <I>unused_oids</I> in | ||||||
|  |     <I>pgsql/src/include/catalog</I> that shows the unused oids.</P> | ||||||
|  |  | ||||||
| When adding system types, you will need to assign oids to them. |     <H3><A name="2">2</A>) What books are good for developers?</H3> | ||||||
| There is also a script called <I>unused_oids</I> in |  | ||||||
| <I>pgsql/src/include/catalog</I> that shows the unused oids. |  | ||||||
|  |  | ||||||
| <H3><a name="2">2</a>)	What books are good for developers?</H3><P> |     <P>I have four good books, <I>An Introduction to Database | ||||||
|  |     Systems,</I> by C.J. Date, Addison, Wesley, <I>A Guide to the SQL | ||||||
|  |     Standard,</I> by C.J. Date, et. al, Addison, Wesley, | ||||||
|  |     <I>Fundamentals of Database Systems,</I> by Elmasri and Navathe, | ||||||
|  |     and <I>Transaction Processing,</I> by Jim Gray, Morgan, | ||||||
|  |     Kaufmann</P> | ||||||
|  |  | ||||||
| I have four good books, <I>An Introduction to Database Systems,</I> by |     <P>There is also a database performance site, with a handbook | ||||||
| C.J. Date, Addison, Wesley, <I>A Guide to the SQL Standard,</I> by C.J. |     on-line written by Jim Gray at <A href= | ||||||
| Date, et. al, Addison, Wesley, <I>Fundamentals of Database Systems,</I> |     "http://www.benchmarkresources.com">http://www.benchmarkresources.com.</A></P> | ||||||
| by Elmasri and Navathe, and <I>Transaction Processing,</I> by Jim Gray, |  | ||||||
| Morgan, Kaufmann<P> |  | ||||||
|  |  | ||||||
| There is also a database performance site, with a handbook on-line |     <H3><A name="3">3</A>) Why do we use <I>palloc</I>() and | ||||||
| written by Jim Gray at <A |     <I>pfree</I>() to allocate memory?</H3> | ||||||
| HREF="http://www.benchmarkresources.com">http://www.benchmarkresources.com.</A> |  | ||||||
|  |  | ||||||
|  |     <P><I>palloc()</I> and <I>pfree()</I> are used in place of malloc() | ||||||
|  |     and free() because we automatically free all memory allocated when | ||||||
|  |     a transaction completes. This makes it easier to make sure we free | ||||||
|  |     memory that gets allocated in one place, but only freed much later. | ||||||
|  |     There are several contexts that memory can be allocated in, and | ||||||
|  |     this controls when the allocated memory is automatically freed by | ||||||
|  |     the backend.</P> | ||||||
|  |  | ||||||
|  |     <H3><A name="4">4</A>) Why do we use <I>Node</I> and <I>List</I> to | ||||||
|  |     make data structures?</H3> | ||||||
|  |  | ||||||
| <H3><a name="3">3</a>)	Why do we use <I>palloc</I>() and <I>pfree</I>() |     <P>We do this because this allows a consistent way to pass data | ||||||
| to allocate memory?</H3><P> |     inside the backend in a flexible way. Every node has a | ||||||
|  |     <I>NodeTag</I> which specifies what type of data is inside the | ||||||
|  |     Node. <I>Lists</I> are groups of <I>Nodes chained together as a | ||||||
|  |     forward-linked list.</I></P> | ||||||
|  |  | ||||||
| <I>palloc()</I> and <I>pfree()</I> are used in place of malloc() and |     <P>Here are some of the <I>List</I> manipulation commands:</P> | ||||||
| free() because we automatically free all memory allocated when a |  | ||||||
| transaction completes.  This makes it easier to make sure we free memory |  | ||||||
| that gets allocated in one place, but only freed much later.  There are |  | ||||||
| several contexts that memory can be allocated in, and this controls when |  | ||||||
| the allocated memory is automatically freed by the backend.<P> |  | ||||||
|  |  | ||||||
|  |     <BLOCKQUOTE> | ||||||
|  |       <DL> | ||||||
|  |         <DT>lfirst(i)</DT> | ||||||
|  |  | ||||||
| <H3><a name="4">4</a>)	Why do we use <I>Node</I> and <I>List</I> to |         <DD>return the data at list element <I>i.</I></DD> | ||||||
| make data structures?</H3><P> |  | ||||||
|  |  | ||||||
| We do this because this allows a consistent way to pass data inside the |         <DT>lnext(i)</DT> | ||||||
| backend in a flexible way.  Every node has a <I>NodeTag</I> which |  | ||||||
| specifies what type of data is inside the Node.  <I>Lists</I> are groups |         <DD>return the next list element after <I>i.</I></DD> | ||||||
| of <I>Nodes chained together as a forward-linked list.</I><P> |  | ||||||
| Here are some of the <I>List</I> manipulation commands: |         <DT>foreach(i, list)</DT> | ||||||
| <BLOCKQUOTE> |  | ||||||
| <DL> |         <DD> | ||||||
| <DT>lfirst(i) |           loop through <I>list,</I> assigning each list element to | ||||||
| <DD>return the data at list element <I>i.</I> |           <I>i.</I> It is important to note that <I>i</I> is a List *, | ||||||
| <DT>lnext(i) |           not the data in the <I>List</I> element. You need to use | ||||||
| <DD>return the next list element after <I>i.</I> |           <I>lfirst(i)</I> to get at the data. Here is a typical code | ||||||
| <DT>foreach(i, list) |           snipped that loops through a List containing <I>Var *'s</I> | ||||||
| <DD>loop through <I>list,</I> assigning each list element to <I>i.</I> |           and processes each one:  | ||||||
| It is important to note that <I>i</I> is a List *, not the data in the |  | ||||||
| <I>List</I> element.  You need to use <I>lfirst(i)</I> to get at the data.  |  | ||||||
| Here is a typical code snipped that loops through a List containing |  | ||||||
| <I>Var *'s</I> and processes each one: |  | ||||||
| <PRE> | <PRE> | ||||||
| <CODE> | <CODE>List *i, *list; | ||||||
|     List *i, *list; |  | ||||||
|      |      | ||||||
|     foreach(i, list) |     foreach(i, list) | ||||||
|     { |     { | ||||||
| @@ -217,281 +233,306 @@ Here is a typical code snipped that loops through a List containing | |||||||
|     } |     } | ||||||
| </CODE> | </CODE> | ||||||
| </PRE> | </PRE> | ||||||
| <DT>lcons(node, list) |         </DD> | ||||||
| <DD>add <I>node</I> to the front of <I>list,</I> or create a new list with |  | ||||||
| <I>node</I> if <I>list</I> is <I>NIL.</I> |         <DT>lcons(node, list)</DT> | ||||||
| <DT>lappend(list, node) |  | ||||||
| <DD>add <I>node</I> to the end of <I>list.</I>  This is more expensive |         <DD>add <I>node</I> to the front of <I>list,</I> or create a | ||||||
| that lcons. |         new list with <I>node</I> if <I>list</I> is <I>NIL.</I></DD> | ||||||
| <DT>nconc(list1, list2) |  | ||||||
| <DD>Concat <I>list2</I> on to the end of <I>list1.</I> |         <DT>lappend(list, node)</DT> | ||||||
| <DT>length(list) |  | ||||||
| <DD>return the length of the <I>list.</I> |         <DD>add <I>node</I> to the end of <I>list.</I> This is more | ||||||
| <DT>nth(i, list) |         expensive that lcons.</DD> | ||||||
| <DD>return the <I>i</I>'th element in <I>list.</I> |  | ||||||
| <DT>lconsi, ... |         <DT>nconc(list1, list2)</DT> | ||||||
| <DD>There are integer versions of these:  <I>lconsi, lappendi, nthi.</I> |  | ||||||
| <I>List's</I> containing integers instead of Node pointers are used to |         <DD>Concat <I>list2</I> on to the end of <I>list1.</I></DD> | ||||||
| hold list of relation object id's and other integer quantities. |  | ||||||
| </DL> |         <DT>length(list)</DT> | ||||||
| </BLOCKQUOTE> |  | ||||||
| You can print nodes easily inside <I>gdb.</I>  First, to disable |         <DD>return the length of the <I>list.</I></DD> | ||||||
| output truncation when you use the gdb <I>print</I> command: |  | ||||||
|  |         <DT>nth(i, list)</DT> | ||||||
|  |  | ||||||
|  |         <DD>return the <I>i</I>'th element in <I>list.</I></DD> | ||||||
|  |  | ||||||
|  |         <DT>lconsi, ...</DT> | ||||||
|  |  | ||||||
|  |         <DD>There are integer versions of these: <I>lconsi, lappendi, | ||||||
|  |         nthi.</I> <I>List's</I> containing integers instead of Node | ||||||
|  |         pointers are used to hold list of relation object id's and | ||||||
|  |         other integer quantities.</DD> | ||||||
|  |       </DL> | ||||||
|  |     </BLOCKQUOTE> | ||||||
|  |     You can print nodes easily inside <I>gdb.</I> First, to disable | ||||||
|  |     output truncation when you use the gdb <I>print</I> command:  | ||||||
| <PRE> | <PRE> | ||||||
| <CODE> | <CODE>(gdb) set print elements 0 | ||||||
| 	(gdb) set print elements 0 |  | ||||||
| </CODE> | </CODE> | ||||||
| </PRE> | </PRE> | ||||||
| Instead of printing values in gdb format, you can use the next two |     Instead of printing values in gdb format, you can use the next two | ||||||
| commands to print out List, Node, and structure contents in a verbose |     commands to print out List, Node, and structure contents in a | ||||||
| format that is easier to understand.  List's are unrolled into nodes, |     verbose format that is easier to understand. List's are unrolled | ||||||
| and nodes are printed in detail.  The first prints in a short format, |     into nodes, and nodes are printed in detail. The first prints in a | ||||||
| and the second in a long format: |     short format, and the second in a long format:  | ||||||
| <PRE> | <PRE> | ||||||
| <CODE> | <CODE>(gdb) call print(any_pointer) | ||||||
| 	(gdb) call print(any_pointer) |  | ||||||
|     (gdb) call pprint(any_pointer) |     (gdb) call pprint(any_pointer) | ||||||
| </CODE> | </CODE> | ||||||
| </PRE> | </PRE> | ||||||
| The output appears in the postmaster log file, or on your screen if you |     The output appears in the postmaster log file, or on your screen if | ||||||
| are running a backend directly without a postmaster. |     you are running a backend directly without a postmaster.  | ||||||
| <P> |  | ||||||
|  |  | ||||||
| <H3><a name="5">5</a>)	How do I add a feature or fix a bug?</H3><P> |     <H3><A name="5">5</A>) How do I add a feature or fix a bug?</H3> | ||||||
|  |  | ||||||
| The source code is over 250,000 lines.  Many problems/features are |     <P>The source code is over 250,000 lines. Many problems/features | ||||||
| isolated to one specific area of the code.  Others require knowledge of |     are isolated to one specific area of the code. Others require | ||||||
| much of the source.  If you are confused about where to start, ask the |     knowledge of much of the source. If you are confused about where to | ||||||
| hackers list, and they will be glad to assess the complexity and give |     start, ask the hackers list, and they will be glad to assess the | ||||||
| pointers on where to start.<P> |     complexity and give pointers on where to start.</P> | ||||||
|  |  | ||||||
| Another thing to keep in mind is that many fixes and features can be |     <P>Another thing to keep in mind is that many fixes and features | ||||||
| added with surprisingly little code.  I often start by adding code, then |     can be added with surprisingly little code. I often start by adding | ||||||
| looking at other areas in the code where similar things are done, and by |     code, then looking at other areas in the code where similar things | ||||||
| the time I am finished, the patch is quite small and compact.<P> |     are done, and by the time I am finished, the patch is quite small | ||||||
|  |     and compact.</P> | ||||||
|  |  | ||||||
| When adding code, keep in mind that it should use the existing |     <P>When adding code, keep in mind that it should use the existing | ||||||
| facilities in the source, for performance reasons and for simplicity.  |     facilities in the source, for performance reasons and for | ||||||
| Often a review of existing code doing similar things is helpful.<P> |     simplicity. Often a review of existing code doing similar things is | ||||||
|  |     helpful.</P> | ||||||
|  |  | ||||||
|  |     <H3><A name="6">6</A>) How do I download/update the current source | ||||||
|  |     tree?</H3> | ||||||
|  |  | ||||||
| <H3><a name="6">6</a>)	How do I download/update the current source |     <P>There are several ways to obtain the source tree. Occasional | ||||||
| tree?</H3><P> |     developers can just get the most recent source tree snapshot from | ||||||
|  |     ftp.postgresql.org. For regular developers, you can use CVS. CVS | ||||||
|  |     allows you to download the source tree, then occasionally update | ||||||
|  |     your copy of the source tree with any new changes. Using CVS, you | ||||||
|  |     don't have to download the entire source each time, only the | ||||||
|  |     changed files. Anonymous CVS does not allows developers to update | ||||||
|  |     the remote source tree, though privileged developers can do this. | ||||||
|  |     There is a CVS FAQ on our web site that describes how to use remote | ||||||
|  |     CVS. You can also use CVSup, which has similarly functionality, and | ||||||
|  |     is available from ftp.postgresql.org.</P> | ||||||
|  |  | ||||||
|  |     <P>To update the source tree, there are two ways. You can generate | ||||||
|  |     a patch against your current source tree, perhaps using the | ||||||
|  |     make_diff tools mentioned above, and send them to the patches list. | ||||||
|  |     They will be reviewed, and applied in a timely manner. If the patch | ||||||
|  |     is major, and we are in beta testing, the developers may wait for | ||||||
|  |     the final release before applying your patches.</P> | ||||||
|  |  | ||||||
| There are several ways to obtain the source tree.  Occasional developers |     <P>For hard-core developers, Marc(scrappy@postgresql.org) will give | ||||||
| can just get the most recent source tree snapshot from |     you a Unix shell account on postgresql.org, so you can use CVS to | ||||||
| ftp.postgresql.org.  For regular developers, you can use CVS.  CVS |     update the main source tree, or you can ftp your files into your | ||||||
| allows you to download the source tree, then occasionally update your |     account, patch, and cvs install the changes directly into the | ||||||
| copy of the source tree with any new changes.  Using CVS, you don't have |     source tree.</P> | ||||||
| to download the entire source each time, only the changed files.  |  | ||||||
| Anonymous CVS does not allows developers to update the remote source |  | ||||||
| tree, though privileged developers can do this.  There is a CVS FAQ on |  | ||||||
| our web site that describes how to use remote CVS. You can also use |  | ||||||
| CVSup, which has similarly functionality, and is available from |  | ||||||
| ftp.postgresql.org.<P> |  | ||||||
|  |  | ||||||
| To update the source tree, there are two ways.  You can generate a patch |     <H3><A name="6">6</A>) How do I test my changes?</H3> | ||||||
| against your current source tree, perhaps using the make_diff tools |  | ||||||
| mentioned above, and send them to the patches list.  They will be |  | ||||||
| reviewed, and applied in a timely manner.  If the patch is major, and we |  | ||||||
| are in beta testing, the developers may wait for the final release |  | ||||||
| before applying your patches.<P> |  | ||||||
|  |  | ||||||
| For hard-core developers, Marc(scrappy@postgresql.org) will give you a |     <P>First, use <I>psql</I> to make sure it is working as you expect. | ||||||
| Unix shell account on postgresql.org, so you can use CVS to update the |     Then run <I>src/test/regress</I> and get the output of | ||||||
| main source tree, or you can ftp your files into your account, patch, |     <I>src/test/regress/checkresults</I> with and without your changes, | ||||||
| and cvs install the changes directly into the source tree. <P> |     to see that your patch does not change the regression test in | ||||||
|  |     unexpected ways. This practice has saved me many times. The | ||||||
|  |     regression tests test the code in ways I would never do, and has | ||||||
|  |     caught many bugs in my patches. By finding the problems now, you | ||||||
|  |     save yourself a lot of debugging later when things are broken, and | ||||||
|  |     you can't figure out when it happened.</P> | ||||||
|  |  | ||||||
| <H3><a name="6">6</a>)	How do I test my changes?</H3><P> |     <H3><A name="7">7</A>) I just added a field to a structure. What | ||||||
|  |     else should I do?</H3> | ||||||
|  |  | ||||||
| First, use <I>psql</I> to make sure it is working as you expect.  Then |     <P>The structures passing around from the parser, rewrite, | ||||||
| run <I>src/test/regress</I> and get the output of |     optimizer, and executor require quite a bit of support. Most | ||||||
| <I>src/test/regress/checkresults</I> with and without your changes, to |     structures have support routines in <I>src/backend/nodes</I> used | ||||||
| see that your patch does not change the regression test in unexpected |     to create, copy, read, and output those structures. Make sure you | ||||||
| ways. This practice has saved me many times.  The regression tests test |     add support for your new field to these files. Find any other | ||||||
| the code in ways I would never do, and has caught many bugs in my |     places the structure may need code for your new field. <I>mkid</I> | ||||||
| patches. By finding the problems now, you save yourself a lot of |     is helpful with this (see above).</P> | ||||||
| debugging later when things are broken, and you can't figure out when it |  | ||||||
| happened.<P> |  | ||||||
|  |  | ||||||
|  |     <H3><A name="8">8</A>) Why are table, column, type, function, view | ||||||
|  |     names sometimes referenced as <I>Name</I> or <I>NameData,</I> and | ||||||
|  |     sometimes as <I>char *?</I></H3> | ||||||
|  |  | ||||||
| <H3><a name="7">7</a>)	I just added a field to a structure.  What else |     <P>Table, column, type, function, and view names are stored in | ||||||
| should I do?</H3><P> |     system tables in columns of type <I>Name.</I> Name is a | ||||||
|  |     fixed-length, null-terminated type of <I>NAMEDATALEN</I> bytes. | ||||||
| The structures passing around from the parser, rewrite, optimizer, and |     (The default value for NAMEDATALEN is 32 bytes.)</P> | ||||||
| executor require quite a bit of support.  Most structures have support | <PRE> | ||||||
| routines in <I>src/backend/nodes</I> used to create, copy, read, and output | <CODE>typedef struct nameData | ||||||
| those structures.  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.  <I>mkid</I> is helpful with this (see above).<P> |  | ||||||
|  |  | ||||||
|  |  | ||||||
| <H3><a name="8">8</a>)	Why are table, column, type, function, view |  | ||||||
| names sometimes referenced as <I>Name</I> or <I>NameData,</I> and |  | ||||||
| sometimes as <I>char *?</I></H3><P> |  | ||||||
|  |  | ||||||
| Table, column, type, function, and view names are stored in system |  | ||||||
| tables in columns of type <I>Name.</I>  Name is a fixed-length, |  | ||||||
| null-terminated type of <I>NAMEDATALEN</I> bytes.  (The default value |  | ||||||
| for NAMEDATALEN is 32 bytes.) |  | ||||||
|  |  | ||||||
| <PRE><CODE> |  | ||||||
| 	typedef struct nameData |  | ||||||
|     { |     { | ||||||
|         char        data[NAMEDATALEN]; |         char        data[NAMEDATALEN]; | ||||||
|     } NameData; |     } NameData; | ||||||
|     typedef NameData *Name; |     typedef NameData *Name; | ||||||
| </CODE></PRE> |  | ||||||
|  |  | ||||||
| Table, column, type, function, and view names that come into the |  | ||||||
| backend via user queries are stored as variable-length, null-terminated |  | ||||||
| character strings.<P> |  | ||||||
|  |  | ||||||
| Many functions are called with both types of names, ie. <I>heap_open().</I>  |  | ||||||
| Because the Name type is null-terminated, it is safe to pass it to a |  | ||||||
| function expecting a char *.  Because there are many cases where on-disk |  | ||||||
| names(Name) are compared to user-supplied names(char *), there are many |  | ||||||
| cases where Name and char * are used interchangeably.<P> |  | ||||||
|  |  | ||||||
| <H3><a name="9">9</a>)	How do I efficiently access information in |  | ||||||
| tables from the backend code?</H3><P> |  | ||||||
|  |  | ||||||
| You first need to find the tuples(rows) you are interested in.  There |  | ||||||
| are two ways.  First, <I>SearchSysCache()</I> and related functions |  | ||||||
| allow you to query the system catalogs.  This is the preferred way to |  | ||||||
| access system tables, because the first call to the cache loads the |  | ||||||
| needed rows, and future requests can return the results without |  | ||||||
| accessing the base table.  The caches use system table indexes |  | ||||||
| to look up tuples.  A list of available caches is located in |  | ||||||
| <I>src/backend/utils/cache/syscache.c.</I>  |  | ||||||
| <I>src/backend/utils/cache/lsyscache.c</I> contains many column-specific |  | ||||||
| cache lookup functions.<P> |  | ||||||
|     |  | ||||||
| The rows returned are cache-owned versions of the heap rows.  Therefore, you |  | ||||||
| must not modify or delete the tuple returned by <I>SearchSysCache()</I>.  What |  | ||||||
| you <I>should</I> do is release it with <I>ReleaseSysCache()</I> when you are |  | ||||||
| done using it; this informs the cache that it can discard that tuple if |  | ||||||
| necessary.  If you neglect to call <I>ReleaseSysCache()</I>, then the cache |  | ||||||
| entry will remain locked in the cache until end of transaction, which is |  | ||||||
| tolerable but not very desirable.<P> |  | ||||||
|  |  | ||||||
| If you can't use the system cache, you will need to retrieve the data |  | ||||||
| directly from the heap table, using the buffer cache that is shared by |  | ||||||
| all backends.  The backend automatically takes care of loading the rows |  | ||||||
| into the buffer cache.<P> |  | ||||||
|  |  | ||||||
| Open the table with <I>heap_open().</I>  You can then start a table scan |  | ||||||
| with <I>heap_beginscan(),</I> then use <I>heap_getnext()</I> and |  | ||||||
| continue as long as <I>HeapTupleIsValid()</I> returns true.  Then do a |  | ||||||
| <I>heap_endscan().</I>  <I>Keys</I> can be assigned to the <I>scan.</I>  |  | ||||||
| No indexes are used, so all rows are going to be compared to the keys, |  | ||||||
| and only the valid rows returned.<P> |  | ||||||
|  |  | ||||||
| You can also use <I>heap_fetch()</I> to fetch rows by block |  | ||||||
| number/offset.  While scans automatically lock/unlock rows from the |  | ||||||
| buffer cache, with <I>heap_fetch(),</I> you must pass a <I>Buffer</I> |  | ||||||
| pointer, and <I>ReleaseBuffer()</I> it when completed.<P> |  | ||||||
|  |  | ||||||
| Once you have the row, you can get data that is common to all tuples, |  | ||||||
| like <I>t_self</I> and <I>t_oid,</I> by merely accessing the |  | ||||||
| <I>HeapTuple</I> structure entries. |  | ||||||
| If you need a table-specific column, you should take the HeapTuple |  | ||||||
| pointer, and use the <I>GETSTRUCT()</I> macro to access the |  | ||||||
| table-specific start of the tuple.  You then cast the pointer as a |  | ||||||
| <I>Form_pg_proc</I> pointer if you are accessing the pg_proc table, or |  | ||||||
| <I>Form_pg_type</I> if you are accessing pg_type.  You can then access |  | ||||||
| the columns by using a structure pointer: |  | ||||||
|  |  | ||||||
| <PRE> |  | ||||||
| <CODE> |  | ||||||
| 	((Form_pg_class) GETSTRUCT(tuple))->relnatts |  | ||||||
| </CODE> | </CODE> | ||||||
| </PRE> | </PRE> | ||||||
|  |     Table, column, type, function, and view names that come into the | ||||||
|  |     backend via user queries are stored as variable-length, | ||||||
|  |     null-terminated character strings.  | ||||||
|  |  | ||||||
| You must not directly change <I>live</I> tuples in this way.  The best |     <P>Many functions are called with both types of names, ie. | ||||||
| way is to use <I>heap_modifytuple()</I> and pass it your original |     <I>heap_open().</I> Because the Name type is null-terminated, it is | ||||||
| tuple, and the values you want changed.  It returns a palloc'ed |     safe to pass it to a function expecting a char *. Because there are | ||||||
| tuple, which you pass to <I>heap_replace().</I> |     many cases where on-disk names(Name) are compared to user-supplied | ||||||
|  |     names(char *), there are many cases where Name and char * are used | ||||||
|  |     interchangeably.</P> | ||||||
|  |  | ||||||
| You can delete tuples by passing the tuple's <I>t_self</I> to |     <H3><A name="9">9</A>) How do I efficiently access information in | ||||||
| <I>heap_destroy().</I>  You use <I>t_self</I> for <I>heap_update()</I> too. |     tables from the backend code?</H3> | ||||||
|  |  | ||||||
| Remember, tuples can be either system cache copies, which may go away after |     <P>You first need to find the tuples(rows) you are interested in. | ||||||
| you call <I>ReleaseSysCache()</I>, or read directly from disk buffers, which |     There are two ways. First, <I>SearchSysCache()</I> and related | ||||||
| go away when you <I>heap_getnext()</I>, <I>heap_endscan</I>, or |     functions allow you to query the system catalogs. This is the | ||||||
| <I>ReleaseBuffer()</I>, in the <I>heap_fetch()</I> case. Or it may be a |     preferred way to access system tables, because the first call to | ||||||
| palloc'ed tuple, that you must <I>pfree()</I> when finished. |     the cache loads the needed rows, and future requests can return the | ||||||
|  |     results without accessing the base table. The caches use system | ||||||
|  |     table indexes to look up tuples. A list of available caches is | ||||||
|  |     located in <I>src/backend/utils/cache/syscache.c.</I> | ||||||
|  |     <I>src/backend/utils/cache/lsyscache.c</I> contains many | ||||||
|  |     column-specific cache lookup functions.</P> | ||||||
|  |  | ||||||
| <H3><a name="10">10</a>)	What is elog()?</H3><P> |     <P>The rows returned are cache-owned versions of the heap rows. | ||||||
|  |     Therefore, you must not modify or delete the tuple returned by | ||||||
|  |     <I>SearchSysCache()</I>. What you <I>should</I> do is release it | ||||||
|  |     with <I>ReleaseSysCache()</I> when you are done using it; this | ||||||
|  |     informs the cache that it can discard that tuple if necessary. If | ||||||
|  |     you neglect to call <I>ReleaseSysCache()</I>, then the cache entry | ||||||
|  |     will remain locked in the cache until end of transaction, which is | ||||||
|  |     tolerable but not very desirable.</P> | ||||||
|  |  | ||||||
| <I>elog()</I> is used to send messages to the front-end, and optionally |     <P>If you can't use the system cache, you will need to retrieve the | ||||||
| terminate the current query being processed.  The first parameter is an |     data directly from the heap table, using the buffer cache that is | ||||||
| elog level of <I>NOTICE,</I> <I>DEBUG,</I> <I>ERROR,</I> or |     shared by all backends. The backend automatically takes care of | ||||||
| <I>FATAL.</I> |     loading the rows into the buffer cache.</P> | ||||||
|  |  | ||||||
| <I>NOTICE</I> prints on the user's terminal and the postmaster logs. |     <P>Open the table with <I>heap_open().</I> You can then start a | ||||||
| <I>DEBUG</I> prints only in the postmaster logs.  <I>ERROR</I> prints in |     table scan with <I>heap_beginscan(),</I> then use | ||||||
| both places, and terminates the current query, never returning from the call. |     <I>heap_getnext()</I> and continue as long as | ||||||
| <I>FATAL</I> terminates the backend process. |     <I>HeapTupleIsValid()</I> returns true. Then do a | ||||||
|  |     <I>heap_endscan().</I> <I>Keys</I> can be assigned to the | ||||||
|  |     <I>scan.</I> No indexes are used, so all rows are going to be | ||||||
|  |     compared to the keys, and only the valid rows returned.</P> | ||||||
|  |  | ||||||
| The remaining parameters of <I>elog</I> are a <I>printf</I>-style set of |     <P>You can also use <I>heap_fetch()</I> to fetch rows by block | ||||||
| parameters to print. |     number/offset. While scans automatically lock/unlock rows from the | ||||||
|  |     buffer cache, with <I>heap_fetch(),</I> you must pass a | ||||||
|  |     <I>Buffer</I> pointer, and <I>ReleaseBuffer()</I> it when | ||||||
|  |     completed.</P> | ||||||
|  |  | ||||||
| <H3><a name="11">11</a>)	What is configure all about?</H3><P> |     <P>Once you have the row, you can get data that is common to all | ||||||
|  |     tuples, like <I>t_self</I> and <I>t_oid,</I> by merely accessing | ||||||
|  |     the <I>HeapTuple</I> structure entries. If you need a | ||||||
|  |     table-specific column, you should take the HeapTuple pointer, and | ||||||
|  |     use the <I>GETSTRUCT()</I> macro to access the table-specific start | ||||||
|  |     of the tuple. You then cast the pointer as a <I>Form_pg_proc</I> | ||||||
|  |     pointer if you are accessing the pg_proc table, or | ||||||
|  |     <I>Form_pg_type</I> if you are accessing pg_type. You can then | ||||||
|  |     access the columns by using a structure pointer:</P> | ||||||
|  | <PRE> | ||||||
|  | <CODE>((Form_pg_class) GETSTRUCT(tuple))->relnatts | ||||||
|  | </CODE> | ||||||
|  | </PRE> | ||||||
|  |     You must not directly change <I>live</I> tuples in this way. The | ||||||
|  |     best way is to use <I>heap_modifytuple()</I> and pass it your | ||||||
|  |     original tuple, and the values you want changed. It returns a | ||||||
|  |     palloc'ed tuple, which you pass to <I>heap_replace().</I> You can | ||||||
|  |     delete tuples by passing the tuple's <I>t_self</I> to | ||||||
|  |     <I>heap_destroy().</I> You use <I>t_self</I> for | ||||||
|  |     <I>heap_update()</I> too. Remember, tuples can be either system | ||||||
|  |     cache copies, which may go away after you call | ||||||
|  |     <I>ReleaseSysCache()</I>, or read directly from disk buffers, which | ||||||
|  |     go away when you <I>heap_getnext()</I>, <I>heap_endscan</I>, or | ||||||
|  |     <I>ReleaseBuffer()</I>, in the <I>heap_fetch()</I> case. Or it may | ||||||
|  |     be a palloc'ed tuple, that you must <I>pfree()</I> when finished.  | ||||||
|  |  | ||||||
| The files <I>configure</I> and <I>configure.in</I> are part of the |     <H3><A name="10">10</A>) What is elog()?</H3> | ||||||
| GNU <I>autoconf</I> package.  Configure allows us to test for various |  | ||||||
| capabilities of the OS, and to set variables that can then be tested in |  | ||||||
| C programs and Makefiles.  Autoconf is installed on the PostgreSQL main |  | ||||||
| server.  To add options to configure, edit <I>configure.in,</I> and then |  | ||||||
| run <I>autoconf</I> to generate <I>configure.</I><P> |  | ||||||
|  |  | ||||||
| When <I>configure</I> is run by the user, it tests various OS |     <P><I>elog()</I> is used to send messages to the front-end, and | ||||||
| capabilities, stores those in <I>config.status</I> and |     optionally terminate the current query being processed. The first | ||||||
| <I>config.cache,</I> and modifies a list of <I>*.in</I> files.  For |     parameter is an elog level of <I>NOTICE,</I> <I>DEBUG,</I> | ||||||
| example, if there exists a <I>Makefile.in,</I> configure generates a |     <I>ERROR,</I> or <I>FATAL.</I> <I>NOTICE</I> prints on the user's | ||||||
| <I>Makefile</I> that contains substitutions for all @var@ parameters |     terminal and the postmaster logs. <I>DEBUG</I> prints only in the | ||||||
| found by configure.<P> |     postmaster logs. <I>ERROR</I> prints in both places, and terminates | ||||||
|  |     the current query, never returning from the call. <I>FATAL</I> | ||||||
|  |     terminates the backend process. The remaining parameters of | ||||||
|  |     <I>elog</I> are a <I>printf</I>-style set of parameters to | ||||||
|  |     print.</P> | ||||||
|  |  | ||||||
| When you need to edit files, make sure you don't waste time modifying |     <H3><A name="11">11</A>) What is configure all about?</H3> | ||||||
| files generated by <I>configure.</I>  Edit the <I>*.in</I> file, and |  | ||||||
| re-run <I>configure</I> to recreate the needed file.  If you run <I>make |  | ||||||
| distclean</I> from the top-level source directory, all files derived by |  | ||||||
| configure are removed, so you see only the file contained in the source |  | ||||||
| distribution.<P> |  | ||||||
|  |  | ||||||
| <H3><a name="12">12</a>)	How do I add a new port?</H3><P> |     <P>The files <I>configure</I> and <I>configure.in</I> are part of | ||||||
|  |     the GNU <I>autoconf</I> package. Configure allows us to test for | ||||||
|  |     various capabilities of the OS, and to set variables that can then | ||||||
|  |     be tested in C programs and Makefiles. Autoconf is installed on the | ||||||
|  |     PostgreSQL main server. To add options to configure, edit | ||||||
|  |     <I>configure.in,</I> and then run <I>autoconf</I> to generate | ||||||
|  |     <I>configure.</I></P> | ||||||
|  |  | ||||||
| There are a variety of places that need to be modified to add a new |     <P>When <I>configure</I> is run by the user, it tests various OS | ||||||
| port. First, start in the <I>src/template</I> directory.  Add an |     capabilities, stores those in <I>config.status</I> and | ||||||
| appropriate entry for your OS.  Also, use <I>src/config.guess</I> to add |     <I>config.cache,</I> and modifies a list of <I>*.in</I> files. For | ||||||
| your OS to <I>src/template/.similar.</I>  You shouldn't match the OS |     example, if there exists a <I>Makefile.in,</I> configure generates | ||||||
| version exactly.  The <I>configure</I> test will look for an exact OS |     a <I>Makefile</I> that contains substitutions for all @var@ | ||||||
| version number, and if not found, find a match without version number.  |     parameters found by configure.</P> | ||||||
| Edit <I>src/configure.in</I> to add your new OS.  (See configure item |  | ||||||
| above.) You will need to run autoconf, or patch <I>src/configure</I> |  | ||||||
| too.<P> |  | ||||||
|  |  | ||||||
| Then, check <I>src/include/port</I> and add your new OS file, with |     <P>When you need to edit files, make sure you don't waste time | ||||||
| appropriate values.  Hopefully, there is already locking code in |     modifying files generated by <I>configure.</I> Edit the <I>*.in</I> | ||||||
| <I>src/include/storage/s_lock.h</I> for your CPU.  There is also a |     file, and re-run <I>configure</I> to recreate the needed file. If | ||||||
| <I>src/makefiles</I> directory for port-specific Makefile handling.  |     you run <I>make distclean</I> from the top-level source directory, | ||||||
| There is a <I>backend/port</I> directory if you need special files for |     all files derived by configure are removed, so you see only the | ||||||
| your OS.<P> |     file contained in the source distribution.</P> | ||||||
|  |  | ||||||
| <H3><a name="13">13</a>) What is CommandCounterIncrement()?</H3><P> |     <H3><A name="12">12</A>) How do I add a new port?</H3> | ||||||
|  |  | ||||||
| Normally, transactions can not see the rows they modify.  This allows <CODE> |     <P>There are a variety of places that need to be modified to add a | ||||||
| UPDATE foo SET x = x + 1</CODE> to work correctly.  |     new port. First, start in the <I>src/template</I> directory. Add an | ||||||
| <P> |     appropriate entry for your OS. Also, use <I>src/config.guess</I> to | ||||||
|  |     add your OS to <I>src/template/.similar.</I> You shouldn't match | ||||||
|  |     the OS version exactly. The <I>configure</I> test will look for an | ||||||
|  |     exact OS version number, and if not found, find a match without | ||||||
|  |     version number. Edit <I>src/configure.in</I> to add your new OS. | ||||||
|  |     (See configure item above.) You will need to run autoconf, or patch | ||||||
|  |     <I>src/configure</I> too.</P> | ||||||
|  |  | ||||||
| However, there are cases where a transactions needs to see rows affected |     <P>Then, check <I>src/include/port</I> and add your new OS file, | ||||||
| in previous parts of the transaction. This is accomplished using a |     with appropriate values. Hopefully, there is already locking code | ||||||
| Command Counter. Incrementing the counter allows transactions to be |     in <I>src/include/storage/s_lock.h</I> for your CPU. There is also | ||||||
| broken into pieces so each piece can see rows modified by previous |     a <I>src/makefiles</I> directory for port-specific Makefile | ||||||
| pieces. <I>CommandCounterIncrement()</I> increments the Command |     handling. There is a <I>backend/port</I> directory if you need | ||||||
| Counter, creating a new part of the transaction. <P> |     special files for your OS.</P> | ||||||
|  |  | ||||||
| </BODY> |     <H3><A name="13">13</A>) What is CommandCounterIncrement()?</H3> | ||||||
|  |  | ||||||
|  |     <P>Normally, transactions can not see the rows they modify. This | ||||||
|  |     allows <CODE>UPDATE foo SET x = x + 1</CODE> to work correctly.</P> | ||||||
|  |  | ||||||
|  |     <P>However, there are cases where a transactions needs to see rows | ||||||
|  |     affected in previous parts of the transaction. This is accomplished | ||||||
|  |     using a Command Counter. Incrementing the counter allows | ||||||
|  |     transactions to be broken into pieces so each piece can see rows | ||||||
|  |     modified by previous pieces. <I>CommandCounterIncrement()</I> | ||||||
|  |     increments the Command Counter, creating a new part of the | ||||||
|  |     transaction.</P> | ||||||
|  |  | ||||||
|  |     <H3><A name="14">14</A>) Why don't we use threads in the | ||||||
|  |     backend?</H3> | ||||||
|  |  | ||||||
|  |     <P>There are several reasons threads are not used:</P> | ||||||
|  |  | ||||||
|  |     <UL> | ||||||
|  |       <LI>Historically, threads were unsupported and buggy.</LI> | ||||||
|  |  | ||||||
|  |       <LI>An error in one backend can corrupt other backends.</LI> | ||||||
|  |  | ||||||
|  |       <LI>Speed improvements using threads are small compared to the | ||||||
|  |       remaining backend startup time.</LI> | ||||||
|  |  | ||||||
|  |       <LI>The backend code would be more complex.</LI> | ||||||
|  |     </UL> | ||||||
|  |   </BODY> | ||||||
| </HTML> | </HTML> | ||||||
|  |  | ||||||
|   | |||||||
		Reference in New Issue
	
	Block a user