Commit bf1dd3ec authored by Bruce Momjian's avatar Bruce Momjian

Update FAQ's for release.

parent bafe9e50
This diff is collapsed.
Developer's Frequently Asked Questions (FAQ) for PostgreSQL
Last updated: Fri Oct 2 15:21:32 EDT 1998
Last updated: Mon Feb 22 17:15:06 EST 1999
Current maintainer: Bruce Momjian (maillist@candle.pha.pa.us)
......@@ -67,7 +67,7 @@ s
Third, you need to get mkid from ftp.postgresql.org. By running
tools/make_mkid, an archive of source symbols can be created that can
be rapidly queried like grep or edited.
be rapidly queried like grep or edited. Others prefer glimpse.
make_diff has tools to create patch diff files that can be applied to
the distribution.
......@@ -105,22 +105,72 @@ s
We do this because this allows a consistent way to pass data inside
the backend in a flexible way. Every node has a NodeTag which
specifies what type of data is inside the Node. Lists are lists of
Nodes. lfirst(), lnext(), and foreach() are used to get, skip, and
traverse through Lists.
specifies what type of data is inside the Node. Lists are groups of
Nodes chained together as a forward-linked list.
Here are some of the List manipulation commands:
lfirst(i)
return the data at list element i.
lnext(i)
return the next list element after i.
foreach(i, list)
loop through list, assigning each list element to i. It is
important to note that i is a List *, not the data in the List
element. You need to use lfirst(i) to get at the data. Here is
a typical code snipped that loops through a List containing Var
*'s and processes each one:
List *i, *list;
foreach(i, list)
{
Var *var = lfirst(i);
/* process var here */
}
lcons(node, list)
add node to the front of list, or create a new list with node
if list is NIL.
lappend(list, node)
add node to the end of list. This is more expensive that lcons.
nconc(list1, list2)
Concat list2 on to the end of list1.
length(list)
return the length of the list.
nth(i, list)
return the i'th element in list.
lconsi, ...
There are integer versions of these: lconsi, lappendi, nthi.
List's containing integers instead of Node pointers are used to
hold list of relation object id's and other integer quantities.
You can print nodes easily inside gdb. First, to disable output
truncation:
truncation when you use the gdb print command:
(gdb) set print elements 0
You may then use either of the next two commands to print out List,
Node, and structure contents. The first prints in a short format, and
the second in a long format:
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
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 the second in a long format:
(gdb) call print(any_pointer)
(gdb) call pprint(any_pointer)
The output appears in the postmaster log file, or on your screen if
you are running a backend directly without a postmaster.
5) How do I add a feature or fix a bug?
The source code is over 250,000 lines. Many problems/features are
......@@ -197,7 +247,7 @@ s
} NameData;
typedef NameData *Name;
Table, column, type, function, and view names that come in to the
Table, column, type, function, and view names that come into the
backend via user queries are stored as variable-length,
null-terminated character strings.
......@@ -244,12 +294,12 @@ s
While scans automatically lock/unlock rows from the buffer cache, with
heap_fetch(), you must pass a Buffer pointer, and ReleaseBuffer() it
when completed. Once you have the row, you can get data that is common
to all tuples, like t_ctid and t_oid, by mererly accessing the
to all tuples, like t_self and t_oid, by mererly accessing the
HeapTuple structure entries. If you need a table-specific column, you
should take the HeapTuple pointer, and use the GETSTRUCT() macro to
access the table-specific start of the tuple. You then cast the
pointer as a Form_pg_proc pointer if you are accessing the pg_proc
table, or TypeTupleForm if you are accessing pg_type. You can then
table, or Form_pg_type if you are accessing pg_type. You can then
access the columns by using a structure pointer:
((Form_pg_class) GETSTRUCT(tuple))->relnatts
......@@ -258,7 +308,7 @@ s
is to use heap_tuplemodify() and pass it your palloc'ed tuple, and the
values you want changed. It returns another palloc'ed tuple, which you
pass to heap_replace(). You can delete tuples by passing the tuple's
t_ctid to heap_destroy(). Remember, tuples can be either system cache
t_self to heap_destroy(). Remember, tuples can be either system cache
versions, which may go away soon after you get them, buffer cache
version, which will go away when you heap_getnext(), heap_endscan, or
ReleaseBuffer(), in the heap_fetch() case. Or it may be a palloc'ed
......
=======================================================
Frequently Asked Questions (FAQ) for PostgreSQL V6.4
HP-UX Specific
......@@ -10,19 +11,19 @@ original author: Tom Lane (tgl@sss.pgh.pa.us)
Questions covered here:
1.1) What do I need to install PostgreSQL on HP-UX?
1.2) Anything special about the build/install procedure?
1.3) yacc dies trying to process src/backend/parser/gram.y.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
1.5) OK, it seemed to build and install, but the regression test fails.
1.1) What do I need to install PostgreSQL on HP-UX?
1.2) Anything special about the build/install procedure?
1.3) yacc dies trying to process src/backend/parser/gram.y.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
1.5) OK, it seemed to build and install, but the regression test fails.
----------------------------------------------------------------------
Section 1: Installing PostgreSQL
----------------------------------------------------------------------
1.1) What do I need to install PostgreSQL on HP-UX?
1.1) What do I need to install PostgreSQL on HP-UX?
PostgreSQL 6.4 is known to build and pass regression test on HPUX 9.03,
9.05, and 10.20, given appropriate system patch levels and build tools.
......@@ -53,14 +54,14 @@ install on HPUX, so I recommend you not bother with anything older
than 6.4.
1.2) Anything special about the build/install procedure?
1.2) Anything special about the build/install procedure?
When you run configure, you will want to explicitly select either the
hpux_cc or hpux_gcc template depending on which compiler you plan to
use:
./configure --with-template=hpux_cc
./configure --with-template=hpux_cc
for HP's C compiler, or
./configure --with-template=hpux_gcc
./configure --with-template=hpux_gcc
for GNU gcc. (If you omit --with-template, configure may either
default to hpux_cc or give up entirely, depending on which HPUX and
PostgreSQL releases you have.)
......@@ -86,7 +87,7 @@ Otherwise the standard build/install procedure described in the
PostgreSQL documentation works fine.
1.3) yacc dies trying to process src/backend/parser/gram.y.
1.3) yacc dies trying to process src/backend/parser/gram.y.
HP's yacc doesn't create its tables large enough to handle the Postgres
grammar (a lot of other vendors' yaccs have this problem too). There
......@@ -106,15 +107,15 @@ are using HP's cc on HPUX 9 --- see next item.
3. Increase yacc's table sizes enough to cope. With a pre-6.4
PostgreSQL grammar, I was able to get HPUX 9's yacc to work by
setting YFLAGS to
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
(You can edit YFLAGS either in the template file before running
configure, or in src/Makefile.global afterwards.) Future PostgreSQL
releases might require even larger tables, but this should do for
a starting point.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
If you're using HP's cc on HPUX 9, it's right: there's no alloca
function. The only place in PostgreSQL that uses alloca is the parser
......@@ -131,7 +132,7 @@ There are several possible answers:
before Y2K anyway...
1.5) OK, it seemed to build and install, but the regression test fails.
1.5) OK, it seemed to build and install, but the regression test fails.
There are several "expected failures" due to differences between HPUX
and the regression test reference platform used by the PostgreSQL group.
......@@ -139,26 +140,26 @@ A look at the textual differences between the expected and actual
outputs will usually reveal that the differences are minor. You should
expect these differences:
TEST(S) COMMENTS
TEST(S) COMMENTS
int2, int4: pg_atoi generates a differently worded error
message for integer overflow.
int2, int4: pg_atoi generates a differently worded error
message for integer overflow.
float8: In 6.4, float8 shows some differences due to
different handling of overflow/underflow errors in
exp() and pow(). This should be fixed in 6.4.1
and later.
float8: In 6.4, float8 shows some differences due to
different handling of overflow/underflow errors in
exp() and pow(). This should be fixed in 6.4.1
and later.
float8, geometry: Lots of differences in the last digit or two
because of different roundoff errors in floating
arithmetic. Also, HPUX does not distinguish
-0 from 0 during printout, but the reference
platform does.
float8, geometry: Lots of differences in the last digit or two
because of different roundoff errors in floating
arithmetic. Also, HPUX does not distinguish
-0 from 0 during printout, but the reference
platform does.
horology: HPUX time library does not know about daylight
savings time before 1970, so there are some
places in horology where a time will be shown
in PST instead of PDT.
horology: HPUX time library does not know about daylight
savings time before 1970, so there are some
places in horology where a time will be shown
in PST instead of PDT.
In addition, the int8 regression test will fail massively on HPUX 9,
because int8 doesn't actually work on this platform (sprintf/sscanf
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -280,6 +280,8 @@ Fix GROUP BY in INSERT INTO table SELECT * FROM table2(Jan)
Fix for computations in views(Jan)
Fix for aggregates on array indexes(Tom)
Fix for DEFAULT handles single quotes in value requiring too many quotes
Fix security problem with non-super users importing/exporting large objects(Tom)
Rollback of transaction that creates table cleaned up properly(Tom)
Enhancements
------------
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment