but I think it's OK now...

can be generated in a buffer and then sent to the frontend in a single
libpq call.  This solves problems with NOTICE and ERROR messages generated
in the middle of a data message or COPY OUT operation.

 disabled (commented-out) in the code.

pg_proc entries for array I/O routines besides the one detected by the
original patcher.  Tighten type_sanity regress test accordingly.

instead of doing a kill(self, SIGQUIT) and expecting the signal handler
to do it.  Also, clean up inconsistent definitions of the sigjmp buffer
in the several files that already referenced it.

and related files.  Also remove float.c's gratuitous redeclaration of
isinf() ... looks like there are more decls in there that ought to be
in config.h, but I'll leave well enough alone for now ...

expression context (ie, not at the top level of a WHERE clause).  Examples
like this one work now:
SELECT name, value FROM t1 as touter WHERE
(value/(SELECT AVG(value) FROM t1 WHERE name = touter.name)) > 0.75;

This fixes a few of the problems Hiroshi Inoue complained of, but
I have not touched the rewrite-related issues.

delete the default argument from the node.  This prevents the executor
from spitting up on the untransformed argument expression.  Typical
failure was:
select (case f1 when 'val' then 'subst' else f1 end) from t1;
ERROR:  copyObject: don't know how to copy 704

work the way it used to (ie, assume xyz is the name of the builtin
function to call).  Complain if an unknown builtin function name is
referenced.

MyProcPid global variable is set to 0 when postgres starts as a command
(not as a backend daemon). This leads issuing SIGQUIT to the process group,
not the process itself. As a result, parent sh gets core dumped in the
Wisconsin benchmark test.

	- change temp -> temp_bench ("temp" is now a reserved word)
	- fix bugs in queries
	- add -B 256 option to run the postgres command
	  (without this, postgres seems to fail with hashjoin)

 rather than reusing the input storage.
Also made the same fix to int8smaller(), though there wasn't a symptom,
 and went through and verified that other pass-by-reference data types
 do the same thing. Not an issue for the by-value types.

   Attached is new README.locale. Should go into .../doc. Includes
instructions on how to install and use Multibyte support. Primarily
oriented toward Russian (Cyrillic) users.

Oleg.
----
    Oleg Broytmann     http://members.xoom.com/phd2/     phd2@earthling.net
           Programmers don't die, they just GOSUB without RETURN.

relation, rather than zeroes.  This prevents the optimizer from making
foolish choices (ie, using nested-loop plans) on never-yet-vacuumed tables.
This is a hack, of course.  Keeping accurate track of these statistics
would be a cleaner solution, but it's far from clear that it'd be worth
the cost of doing so.  In any case we're not going to do that for 6.5.
In the meantime, this quick hack provides a useful performance improvement
in the regression tests and in many real-world scenarios.

in rules regression test, in order to eliminate bogus test 'failures'
that occur due to platform-dependent and join-implementation-dependent
ordering of tuples.  I'm not sure that I got all of the SELECTs that need
ordering clauses --- we may need some more.  But this takes care of the
diffs between my platform and Jan's.

sourced with \i (tried to read data from the terminal, rather than from
the source file; this breaks pg_dump scripts read with \i).  Also, \o file
followed by COPY TO STDOUT wrote to terminal not designated file.
All better now.

 sharing across files.

 time zone.
Previously, localtime() rotated a date with a day of month field which
 exceeded the actual range into the next months, masking the fact that
 a bad date had been specified.
Regression tests pass.

 mis-copied "NULL", which happens to have the same binary value.
Previously, gcc gave non-fatal warnings.

Previously, dates falling within Unix system time range were run through
 a call to localtime() to get the time zone, if it was not specified.
This had the effect that dates with DOMs which were larger than would be
 valid for that month were "rotated" into the following months.

 machine (linux-2.0.36 RH5.2 with RH5.2 patches).

not match what the backend actually accepts.