corochoone@gmail.com

usage of any information from system catalog, because it could be called during
replay of WAL.

Per bug report from Craig McElroy <craig.mcelroy@contegix.com>. Patch doesn't
change on-disk storage.

the imports for. Add RegisterWaitForSingleObject() to the list of such
functions, which should take care of the current buildfarm breakage.

for this.

excerpts of a document.  That's clearly desirable, but the functionality
is not there yet.

mentioned updating FAQ_IRIX for information about buggy MIPSPro
compiler version, now confirmed by Herve Boulouis.

errno string when complaining of fopen failures.  Per gripe from Bob
Pawley, it's not always instantly obvious to the user which name we
tried to open.

that have default expressions different from their parent.  First, if the
parent table's default expression has to be split out as a separate
ALTER TABLE command, we need a dependency constraint to ensure that the
child's command is given second.  This is because the ALTER TABLE on the
parent will propagate to the child.  (We can't prevent that by using ONLY on
the parent's command, since it's possible that other children exist that
should receive the inherited default.)  Second, if the child has a NULL
default where the parent does not, we have to explicitly say DEFAULT NULL on
the child in order for this state to be preserved after reload.  (The latter
actually doesn't work right because of a backend bug, but that is a separate
issue.)

Backpatch as far as 8.0.  7.x pg_dump has enough issues with altered tables
(due to lack of dependency analysis) that trying to fix this one doesn't seem
very productive.

containing decimal points aren't considered part of a hyphenated word.
Sync the hyphenated-word lookahead states with the subsequent part-by-part
reparsing states so that we don't get different answers about how much text
is part of the hyphenated word.  Per my gripe of a few days ago.

in debugging its state-machine rules.  Const-ify all the constant tables.
Minor other code cleanup, including using "token" rather than "lexeme" to
describe the output strings.

per recommendation from Alvaro.  This doesn't force initdb since the
numeric token type in the catalogs doesn't change; but note that
the expected regression test output changed.

This doubles the planning workload for mergejoins while not actually
accomplishing much.  The only useful case is where one of the directions
matches the query's ORDER BY request; therefore, put a thumb on the scales
in that direction, and otherwise arbitrarily consider only the ASC direction.
(This is a lot easier now than it would've been before 8.3, since we have
more semantic knowledge embedded in PathKeys now.)

hyphenated-word parser examples per earlier discussion with Alvaro.

childprocess deaths instead of using one thread per child. This drastastically
reduces the address space usage and should allow for more backends running.

Also change the win32_waitpid functionality to use an IO Completion Port for
queueing child death notices instead of using a fixed-size array.

to be locking another process (except when it's working to prevent Xid
wraparound problems).

cases.

if either of the input relations can legally be joined to any other rels using
join clauses.  This avoids uselessly (and expensively) considering a lot of
really stupid join paths when there is a join restriction with a large
footprint, that is, lots of relations inside its LHS or RHS.  My patch of
15-Feb-2007 had been causing the code to consider joining *every* combination
of rels inside such a group, which is exponentially bad :-(.  With this
behavior, clauseless bushy joins will be done if necessary, but they'll be
put off as long as possible.  Per report from Jakub Ouhrabka.

Backpatch to 8.2.  We might someday want to backpatch to 8.1 as well, but 8.1
does not have the problem for OUTER JOIN nests, only for IN-clauses, so it's
not clear anyone's very likely to hit it in practice; and the current patch
doesn't apply cleanly to 8.1.

Per gripe from Zdenek Kotala, though not exactly his patch.

Jun Kuwamura

Ulrich Kroener

only on the 'language' part of the locale name, ignoring the country code.
We may need to be smarter later when there are more built-in configurations,
but for now this is good enough and avoids having to bloat the table.

transaction end, in case we decide to do a vacuum analyze (which is done in two
xacts).

the sequence.  Also, make setval() with is_called = false not affect the
currval state, either.  Per report from Kris Jurka that an implicit
ALTER SEQUENCE OWNED BY unexpectedly caused currval() to become valid.
Since this isn't 100% backwards compatible, it will go into HEAD only;
I'll put a more limited patch into 8.2.

Also, remove redundant reset of for-wraparound PGPROC flag.

Thanks to Tom Lane for noticing both bogosities.

(Last night I copied-and-pasted from the WITH HOLD case, but that's
wrong because of the bizarrely irregular syntax specified by the standard.)

in corner cases such as re-fetching a just-deleted row.  We may be able to
relax this someday, but let's find out how many people really care before
we invest a lot of work in it.  Per report from Heikki and subsequent
discussion.

While in the neighborhood, make the combination of INSENSITIVE and FOR UPDATE
throw an error, since they are semantically incompatible.  (Up to now we've
accepted but just ignored the INSENSITIVE option of DECLARE CURSOR.)

having several of them.  Add two more flags: whether the process is
executing an ANALYZE, and whether a vacuum is for Xid wraparound (which
is obviously only set by autovacuum).

Sneakily move the worker's recently-acquired PostAuthDelay to a more useful
place.

neglected to test whether an outer join's join-condition actually refers to
the lower outer join it is looking at.  (The comment correctly described what
was supposed to happen, but the code didn't do it...)  This often resulted in
adding an unnecessary constraint on the join order of the two outer joins,
which was bad enough.  However, it also seems to expose a performance
problem in an older patch (from 15-Feb): once we've decided that there is a
join ordering constraint, we will start trying clauseless joins between every
combination of rels within the constraint, which pointlessly eats up lots of
time and space if there are numerous rels below the outer join.  That probably
needs to be revisited :-(.  Per gripe from Jakub Ouhrabka.