C:\msys\1.0\home\y-asaba>pg_ctl -D data restart
	waiting for postmaster to shut down...LOG:  received smart shutdown
	request.
	LOG:  shutting down
	LOG:  database system is shut down
	done
	postmaster stopped

	postmaster starting

	C:\msys\1.0\home\y-asaba>postmaster.exe: invalid argument: "'-D'"
	Try "postmaster.exe --help" for more information.

Yoshiyuki Asaba

- refactor a bunch of code to call a separate function print_msg() which
checks whether "silent mode" is enabled before printing an error
message.

- rename "silence_mode" to "silent_mode", which IMHO makes more sense

- make the error messages we emit in "waiting" mode more consistent; I
believe this fixes a recent error message regression

> * Allow libpq to access SQLSTATE so pg_ctl can test for connection failure
>
>   This would be used for checking if the server is up.
>

for getpid().

<
> * Prevent inet cast to cidr if the unmasked bits are not zero, or
>   zero bits

Reini Urban

and contrib/xml2

- remove another senseless "extern" keyword that was applied to a
function definition
- change a foo more function signatures from "some_type foo()" to
"some_type foo(void)"
- rewrite another K&R style function definition
- make the type of the "action" function pointer in the KeyWord struct
in src/backend/utils/adt/formatting.c more precise

not update some error message text).

> * Add RESET CONNECTION command to reset all session state
329a331,334
>   This would include resetting of all variables (RESET ALL), dropping of
>   all temporary tables, removal of any NOTIFYs, etc.  This could be used
>   for connection pooling.  We could also change RESET ALL to have this
>   functionality.

Urban

argument, leading to label matching failures at run-time.  Per report from
Patrick Fiche.  Also, fix it so that an unrecognized label argument draws
a more useful error message than 'syntax error'.

name, mainly for debugging purposes.

pg_config_paths.h outside of /src/port.

$(LD) -x -Bshareable to $(CC) -shared on OpenBSD (I suspect this
should be carried over to the other two as well, but will refrain
pending suggestions from people who actually use those platforms).
Per Stefan Kaltenbrunner.

for scanning one term of an OR clause if the index's predicate is implied
by that same OR clause term (possibly in conjunction with top-level WHERE
clauses).  Per recent example from Dawid Kuroczko,
http://archives.postgresql.org/pgsql-performance/2004-10/msg00095.php
Also, fix a very long-standing bug in index predicate testing, namely the
bizarre ordering of decomposition of predicate and restriction clauses.
AFAICS the correct way is to break down the predicate all the way, and
then for each component term see if you can prove it from the entire
restriction set.  The original coding had a purely-implementation-artifact
distinction between ANDing at the top level and ANDing below that, and
proceeded to get the decomposition order wrong everywhere below the top
level, with the result that even slightly complicated AND/OR predicates
could not be proven.  For instance, given
create index foop on foo(f2) where f1=42 or f1=1
    or (f1 = 11 and f2 = 55);
the old code would fail to match this index to the query
select * from foo where f1 = 11 and f2 = 55;
when it obviously ought to match.