This isn't very important by itself, but was left on my list of things
without test coverage for the collation feature.

We previously heard of the same problem in int24div(), so there's not a
good reason to suppose the problem is confined to cases involving int8.

Add dummy returns before every potential division-by-zero in int8.c,
because apparently further "improvements" in gcc's optimizer have
enabled it to break functions that weren't broken before.

Aurelien Jarno, via Martin Pitt

CollateClause is now used only in raw grammar output, and CollateExpr after
parse analysis.  This is for clarity and to avoid carrying collation names
in post-analysis parse trees: that's both wasteful and possibly misleading,
since the collation's name could be changed while the parsetree still
exists.

Also, clean up assorted infelicities and omissions in processing of the
node type.

for consistency.

Use collencoding = -1 to represent such a collation in pg_collation.
We need this to make the "default" entry work sanely, and a later
patch will fix the C/POSIX entries to be represented this way instead
of duplicating them across all encodings.  All lookup operations now
search first for an entry that's database-encoding-specific, and then
for the same name with collencoding = -1.

Also some incidental code cleanup in collationcmds.c and pg_collation.c.

variable hiding. A constant is not a variable. It worked in most cases by
accident, because we add constants to the global list of variables (why?),
but float constants like 1.23 were interpreted as struct field references,
and not found.

Backpatch to 9.0, where the test for variable hiding was added.

Removes extraneous closing parenthesis from pg_describe_object
Puts pg_describe_object and has_sequence_privilege in correct
alphabetical position in function listing

Thom Brown

Josh Berkus

to fully process errors.

FREEZE functionality.

suggestion.

backward compatibility.

O_DIRECT behavior.

opposed to O_DSYNC.

complex quoting, e.g. -t and -n.

Including collation in the behavior of that function promotes a world view
we do not want.  Moreover, it was producing the wrong behavior for pg_dump
anyway: what we want is to dump a COLLATE clause on attributes whose
attcollation is different from the underlying type, and likewise for
domains, and the function cannot do that for us.  Doing it the hard way
in pg_dump is a bit more tedious but produces more correct output.

In passing, fix initdb so that the initial entry in pg_collation is
properly pinned.  It was droppable before :-(

It's not a good idea to kill the postmaster just because someone muffs
this, and it's not consistent with what we do for other, similar GUCs.

Fujii Masao, with a bit more hacking by me

Fujii Masao

SyncRepRequested() must check not only the value of the
synchronous_replication GUC but also whether max_wal_senders > 0.
Otherwise, we might end up waiting for sync rep even when there's no
possibility of a standby ever managing to connect.  There are some
existing cross-checks to prevent this, but they're not quite sufficient:
the user can start the server with max_wal_senders=0,
synchronous_standby_names='', and synchronous_replication=off and then
subsequent make synchronous_standby_names not empty using pg_ctl reload,
and then SET synchronous_standby=on, leading to an indefinite hang.

Along the way, rename the global variable for the synchronous_replication
GUC to match the name of the GUC itself, for clarity.

Report by Fujii Masao, though I didn't use his patch.

In earlier versions of the sync rep patch, waiters removed themselves from
the queue, but now walsender removes them before doing the wakeup.

Report by Fujii Masao.

Fujii Masao, with a bit of additional wordsmithing by me.