Per C standard, these are semantically the same thing; but saying NULL
when you mean NULL is good for readability.

Marti Raudsepp, per results of INRIA's Coccinelle.

Now that we're expecting a mergeclause's left_ec/right_ec to persist from
the initial assignments, we can't just blithely zero these out when
transforming such a clause in adjust_appendrel_attrs.  But really it should
be okay to keep the parent's values, since a child table's derived Var
ought to be equivalent to the parent Var for all EquivalenceClass purposes.
(Indeed, I'm wondering whether we couldn't find a way to dispense with
add_child_rel_equivalences altogether.  But this is wrong in any case.)

Zoltan Boszormenyi exhibited a test case in which planning time was
dominated by construction of EquivalenceClasses and PathKeys that had no
actual relevance to the query (and in fact got discarded immediately).
This happened because we generated PathKeys describing the sort ordering of
every index on every table in the query, and only after that checked to see
if the sort ordering was relevant.  The EC/PK construction code is O(N^2)
in the number of ECs, which is all right for the intended number of such
objects, but it gets out of hand if there are ECs for lots of irrelevant
indexes.

To fix, twiddle the handling of mergeclauses a little bit to ensure that
every interesting EC is created before we begin path generation.  (This
doesn't cost anything --- in fact I think it's a bit cheaper than before
--- since we always eventually created those ECs anyway.)  Then, if an
index column can't be found in any pre-existing EC, we know that that sort
ordering is irrelevant for the query.  Instead of creating a useless EC,
we can just not build a pathkey for the index column in the first place.
The index will still be considered if it's useful for non-order-related
reasons, but we will think of its output as unsorted.

FROM STDIN in PL/pgSQL. We alread did this for dynamic EXECUTE statements,
ie. "EXECUTE 'COMMIT'", but not otherwise.

Josh Kupershmidt

The previous wording might have suggested that \du only showed login roles
and \dg only group roles, but that is no longer the case.

proposed by Josh Kupershmidt

Instead of using ExecPrepareExpr, call ExecInitExpr.  The net change here
is that we don't apply expression_planner() to the expression tree.  There
is no need to do so, because that tree is extracted from a fully planned
plancache entry, so all the needed work is already done.  This reduces
the setup costs by about a factor of 2 according to some simple tests.
Oversight noted while fooling around with the simple-expression code for
previous fix.

In general, expression execution state trees aren't re-entrantly usable,
since functions can store private state information in them.
For efficiency reasons, plpgsql tries to cache and reuse state trees for
"simple" expressions.  It can get away with that most of the time, but it
can fail if the state tree is dirty from a previous failed execution (as
in an example from Alvaro) or is being used recursively (as noted by me).

Fix by tracking whether a state tree is in use, and falling back to the
"non-simple" code path if so.  This results in a pretty considerable speed
hit when the non-simple path is taken, but the available alternatives seem
even more unpleasant because they add overhead in the simple path.  Per
idea from Heikki.

Back-patch to all supported branches.

This was only used while the final release notes for 9.0 were being prepared.
The alpha release notes are now in release-9.1.sgml.

This reverts commit 915116bc.

Per discussion, the previous formula was in fact correct.

http://archives.postgresql.org/pgsql-docs/2010-10/msg00038.php

Along the way, clarify that sdparm can be used on Linux as well as FreeBSD.

Try to make the code look self-consistent again, so it doesn't confuse
future developers.

after accepting a connection fails, and the server is compiled with GSSAPI
support. Report and patch by Alexander V. Chernikov, bug #5731.

Original patch failed to include new exclusive states in a switch that
needed to include them; and also was guilty of very fuzzy thinking
about how to handle error cases.  Per bug #5729 from Alan Choi.

Josh Kupershmidt

KaiGai Kohei, with minor cleanup of the comments by me.

- Avoid closing stdin, since we didn't open it.  Previously multiple
inclusions of stdin would be terminated with a single quit, now a separate
quit is needed for each invocation. Previous behavior also accessed stdin
after it was fclose()d, which is undefined behavior per ANSI C.

- Properly restore pset.inputfile, since the caller expects to be able
to free that memory.

Marti Raudsepp

WAL-logged. Make the notice about the lack of WAL-logging more visible by
making it a <caution>. Also remove the false statement from hot standby
caveats section that hash indexes are not used during hot standby.

Report by Peter Eisentraut.

that WAL file containing the checkpoint redo-location can be found. This
avoids making the cluster irrecoverable if the redo location is in an earlie
WAL file than the checkpoint record.

Report, analysis and patch by Jeff Davis, with small changes by me.

Split the old typenameTypeId() into two functions: A new typenameTypeId() that
returns only a type OID, and typenameTypeIdAndMod() that returns type OID and
typmod.  This isolates call sites better that actually care about the typmod.

A NestLoopParam's value can only be a Var or Aggref, but this isn't the
case in general for SubPlan parameters, so print_parameter_expr had better
be prepared to cope.  Brain fade in my recent patch to print the referenced
expression instead of just printing $N for PARAM_EXEC Params.  Per report
from Pavel Stehule.

This avoids a possible crash when inlining a SRF whose argument list
contains a reference to an inline-able user function.  The crash is quite
reproducible with CLOBBER_FREED_MEMORY enabled, but would be less certain
in a production build.  Problem introduced in 9.0 by the named-arguments
patch, which requires invoking eval_const_expressions() before we can try
to inline a SRF.  Per report from Brendan Jurd.

Per previous failure of buildfarm member koi (which is no longer
failing, alas).

After much expenditure of effort, we've got this to the point where the
performance penalty is pretty minimal in typical cases.

Andrew Dunstan, reviewed by Brendan Jurd, Dean Rasheed, and Tom Lane

A name starting with a dot can be used to match a suffix of the actual
host name (e.g., .example.com matches foo.example.com).

Spotted by Alexander Korotkov.

Along the way, remove a misleading comment line.

the docs to reflect that OFF is now unreserved. Spotted by Tom Lane.

as a variable or column name, and it's not reserved in recent versions of
the SQL spec either. This became particularly annoying in 9.0, before that
PL/pgSQL replaced variable names in queries with parameter markers, so
it was possible to use OFF and many other backend parser keywords as
variable names. Because of that, backpatch to 9.0.