pg_internal.init file in-place, which meant that if another backend
started at about the same time, it might read the incomplete file.
init_irels tries to guard against that, but I have now seen a crash
due to reading bad data from a partly-written file.  (This may indicate
a kernel bug on my platform?  Not sure.)  Anyway, clearly the safest
course is to write the new pg_internal.init file under a unique temporary
filename, and rename it into place only after it's all written.

the syntax ... but gram.y doesn't think so.

- I was unable to compile ecpg due to the ":=" instead of "=" in defining
LIBPQDIR and some other variables in Makefile.global.in
- pg_id (and also pg_encoding) executable was not removed during "make
clean" - there was no $(X) appended to the executable name for rm
- I have added result for int2, int4, float8 and geometry regression tests
        - int2, int2 - yet another message for too large numbers ;-)
        - float8 - it is problably a bug in the newlib C library - it has no
error message for numbers with exponent -400
        - geometry - differences in precision of float numbers
- I have added appropriate lines into resultmap file
- I have modified the script regress.sh to use "case" statement when testing
the hostname. For cygwin the script is called with "i686-pc-cygwin" (on my
machine) as a parameter and this was not catched with the "if" statement.
The check was done for PORTNAME (win) and not HOSTNAME (i.86-pc-cygwin*).

The patch for described modifications is included.

All this modifications can be applied to "current" tree too.
The compilation was done on CygwinB20.1 with gcc 2.95, cygipc library 1.05.
The binaries were able to run also on the newest development snapshot
(2000-03-25).

                        Dan

multibyte encodings. These cannot be used as a backend/database encoding
(OK to use as a client encoding).

actually from an alpha-dec-osf machine, but as far as can be told the
two platforms have the same ideas about past DST rules.

Make similar changes to hpux templates.  Might want to do the same for
other foo_cc and foo_gcc pairs, but will desist until I hear from
someone who uses those platforms.

and do not arbitrarily pull in CFLAGS instead.  This caters to platforms
where the C++ compiler does not like all the same switches the C compiler
wants.

In the event of an elog() while the mode was set to immediate write,
there was no way for it to be set back to the normal delayed write.
The mechanism was a waste of space and cycles anyway, since the only user
was varsup.c, which could perfectly well call FlushBuffer directly.
Now it does just that, and the notion of a write mode is gone.

from gcc.  Which wasn't actually a code bug, but I don't like warnings.

Add some chapters on new topics.
Change to referencing OASIS/Docbook v3.1 rather than Davenport/Docbook v3.0
Grepped for and fixed apparent tag mangling from emacs
 "Normalize" operation. Should be the last of those.