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.

This patch eliminates various bizarre behaviors caused by sloppy thinking
about the difference between a domain type and its underlying array type.
In particular, the operation of updating one element of such an array
has to be considered as yielding a value of the underlying array type,
*not* a value of the domain, because there's no assurance that the
domain's CHECK constraints are still satisfied.  If we're intending to
store the result back into a domain column, we have to re-cast to the
domain type so that constraints are re-checked.

For similar reasons, such a domain can't be blindly matched to an ANYARRAY
polymorphic parameter, because the polymorphic function is likely to apply
array-ish operations that could invalidate the domain constraints.  For the
moment, we just forbid such matching.  We might later wish to insert an
automatic downcast to the underlying array type, but such a change should
also change matching of domains to ANYELEMENT for consistency.

To ensure that all such logic is rechecked, this patch removes the original
hack of setting a domain's pg_type.typelem field to match its base type;
the typelem will always be zero instead.  In those places where it's really
okay to look through the domain type with no other logic changes, use the
newly added get_base_element_type function in place of get_element_type.
catversion bumped due to change in pg_type contents.

Per bug #5717 from Richard Huxton and subsequent discussion.

following NULL check was never reached.

This problem was found by Coccinelle (null_ref.cocci from coccicheck).

Marti Raudsepp

outside a transaction.

This repairs brain fade in my patch of 2009-08-30: the reason we had been
storing oldest-database name, not OID, in ShmemVariableCache was of course
to avoid having to do a catalog lookup at times when it might be unsafe.

This error explains why Aleksandr Dushein is having trouble getting out of
an XID wraparound state in bug #5718, though not how he got into that state
in the first place.  I suspect pg_upgrade is at fault there.

This call was present in the aboriginal code from Berkeley, and has
never been touched; it may very well be that it was there to mask
effects of bugs in other places and it may no longer be necessary.
The removal has been foreseen in a code comment since 2007; this seems
to be a good time to test this hypothesis.

The trick is to not try to build executables directly from .c files,
but to always build the intermediate .o files.  For obscure reasons,
Darwin's version of gcc will leave debug cruft behind in the first
case but not the second.  Per complaint from Robert Haas.