This patch causes unknown-type Consts to be coerced to the resolved output
type of the set operation at parse time.  Formerly such Consts were left
alone until late in the planning stage.  The disadvantage of that approach
is that it disables some optimizations, because the planner sees the set-op
leaf query as having different output column types than the overall set-op.
We saw an example of that in a recent performance gripe from Claudio
Freire.

Fixing such a Const requires scribbling on the leaf query in
transformSetOperationTree, but that should be all right since if the leaf
query's semantics depended on that output column, it would already have
resolved the unknown to something else.

Most of the bulk of this patch is a simple adjustment of
transformSetOperationTree's API so that upper levels can get at the
TargetEntry containing a Const to be replaced: it now returns a list of
TargetEntries, instead of just the bare expressions.

Specifically, mention that "restart" is disabled by this parameter.

the comments on the template1 database.  No catalog version bump because
they are just comments.

- Make the name of the ID tag for the GUC entry match the GUC name.
- Clarify that synchronous_replication waits for xlog flush, not receipt.
- Mention that synchronous_replication won't wait if max_wal_senders=0.

Review by Tom Lane.

This was required in pre-8.4 versions to allow the specification of
"ident sameuser", but sameuser is no longer required. It could be extended
to allow all parameters in the future, but should then apply to all
methods and not just ident.

We have a test that verifies that max(anyarray) will cope if the array
column elements aren't all the same array type.  However, it's now possible
for that to produce a collation-related error message instead of the
expected one, if the first two column elements happen to be of the same
type and it's one that expects to be given collation info.  Tweak the test
to ensure this doesn't happen.  Per buildfarm member pika.

Its mechanism for recovering after deleting the current list cell was
a bit klugy.  Borrow the technique used in other places.

While this will give wrong answers when estimating selectivity for a
comparison operator that's using a non-default collation, the estimation
error probably won't be large; and anyway the former approach created
estimation errors of its own by trying to use a histogram that might have
been computed with some other collation.  So we'll adopt this simplified
approach for now and perhaps improve it sometime in the future.

This patch incorporates changes from Andres Freund to make sure that
selfuncs.c passes a valid collation OID to any datatype-specific function
it calls, in case that function wants collation information.  Said OID will
now always be DEFAULT_COLLATION_OID, but at least we won't get errors.

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.