Adjust psql -f - to behave like a normal file and honor the -1 flag.

Report from Robert Haas

locale-dependent character classification properly when the database encoding
is UTF8.

The previous coding worked okay in single-byte encodings, or in any case for
ASCII characters, but failed entirely on multibyte characters.  The fix
assumes that the <wctype.h> functions use Unicode code points as the wchar
representation for Unicode, ie, wchar matches pg_wchar.

This is only a partial solution, since we're still stupid about non-ASCII
characters in multibyte encodings other than UTF8.  The practical effect
of that is limited, however, since those cases are generally Far Eastern
glyphs for which concepts like case-folding don't apply anyway.  Certainly
all or nearly all of the field reports of problems have been about UTF8.
A more general solution would require switching to the platform's wchar
representation for all regex operations; which is possible but would have
substantial disadvantages.  Let's try this and see if it's sufficient in
practice.

Add ProcessUtility_hook() to handle all DDL to
contrib/pg_stat_statements.

Add ProcessUtility_hook() to handle all DDL to contrib/pg_stat_statements.

Itagaki Takahiro

Update hstore docs, mostly word-smithing.

David E. Wheeler

There is no reference to THREAD_SUPPORT outside configure, and it is
never set, so remove it.

Per report from Robert Gravsjö.

branch, which is how most actual code is actually structured.  Also fix
slight whitespace misalignment.

we have to tell Perl it can release its compiled copy of the function
text.  Noted by Alexey Klyukin.

Back-patch to 8.2 --- the problem exists further back, but this patch
won't work without modification, and it's probably not worth the trouble.

arrays in a pg_proc entry match.  Seems like an easy mistake to make when
manually adjusting these values in a pg_proc.h entry.

being hidden when current_query is.  Relocate it to a column position
more consistent with that behavior.  Per discussion.

Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce

pg_stat_activity and recorded in log entries.

Dave Page, reviewed by Andres Freund

Add link to exteran fsync testing script and our fsync test tool.

Improve test descriptions displayed during test_fsync;  increase default
loops to 5k.

by adding a requirement that build_join_rel add new join RelOptInfos to the
appropriate list immediately at creation.  Per report from Robert Haas,
the list_concat_unique_ptr() calls that this change eliminates were taking
the lion's share of the runtime in larger join problems.  This doesn't do
anything to fix the fundamental combinatorial explosion in large join
problems, but it should push out the threshold of pain a bit further.

Note: because this changes the order in which joinrel lists are built,
it might result in changes in selected plans in cases where different
alternatives have exactly the same costs.  There is one example in the
regression tests.

vacuum.

comment.

string too.

in the build process. If not the build process will stop with an error message.

Boszormenyi Zoltan, with only a minor tweak or two from me.

the time, rather than hoping we can tell whether the terminal supports
UTF8 characters.  Per discussion.

Author: Erik Rijkers <er@xs4all.nl>

Author: Euler Taveira de Oliveira <euler@timbira.com>

newline representations.  Per buildfarm results and subsequent discussion.
Sync up a couple of other places that had their own policies.

Hiroshi Saito

be part of multixacts, so allocate a slot for each prepared transaction in
the "oldest member" array in multixact.c. On PREPARE TRANSACTION, transfer
the oldest member value from the current backends slot to the prepared xact
slot. Also save and recover the value from the 2pc state file.

The symptom of the bug was that after a transaction prepared, a shared lock
still held by the prepared transaction was sometimes ignored by other
transactions.

Fix back to 8.1, where both 2PC and multixact were introduced.

a bit more consistent and less obviously written by different people at
different times.

We have used -w for a long time as a means of reducing the reported diff
volume when one element of a result table isn't of the expected width.
However, most of the time the results just pass anyway, so this isn't as
important as it once was.  Meanwhile, the risk of missing potentially
significant deviations has gone up, particularly with psql's ability to
report error cursor positions.  So, let's switch over to space-sensitive
comparisons.  Per my proposal of yesterday.

(All the expected files that I can test here seem to be ready for this
already, but we'll see what the buildfarm thinks about others.)

Jan Urbanski