planning to modify them itself. Otherwise we end up with shared RTE
substructure, which breaks inheritance_planner because the rte->inh
flag needs to be independent in each copied subquery. Per bug report
from Chris Piker.
and hash bucket-size estimation. Issue has been there awhile but is more
critical in 7.4 because it affects varchar columns. Per report from
Greg Stark.
Ward's report that it can still happen in RC2 forces me to realize that
this is not a can't-happen condition after all, and that the compaction
code had better cope rather than panicking.
Vars created to fill subplan args lists. This is an ancient error, going
back at least to 7.0, but is more easily triggered in 7.4 than before
because we no longer compare varlevelsup when deciding whether a Param
slot can be re-used. Fixes bug reported by Klint Gore.
per report from Andrew Holm-Hansen. The difficulty arises from the fact
that the planner allowed a Hash node's hashkeys to share substructure
with the parent HashJoin node's hashclauses, plus some rather bizarre
choices about who initializes what during executor startup. A cleaner
but more invasive solution is to not store hashkeys separately in the
plan tree at all, but let the HashJoin node deconstruct hashclauses
during executor startup. I plan to fix it that way in HEAD.
tree for CYCLE option; don't assume zeros are invalid values for sequence
fields other than increment_by; don't reset cache_value when not told to;
simplify code for testing whether to apply defaults.
which had been unintentionally broken by recent changes to tighten up the
DateStyle rules for all-numeric date input. Add documentation and
regression tests for this, too.
couple months ago: the >= and > operators were swapped. Not worth
forcing an initdb for this, but we should get it right in the release.
Will be patched separately in HEAD.
regression=# select 1 from tenk1 ta cross join tenk1 tb for update;
ERROR: no relation entry for relid 3
7.3 said "SELECT FOR UPDATE cannot be applied to a join", which was better
but still wrong, considering that 7.2 took the query just fine. Fix by
making transformForUpdate() ignore JOIN and other special RTE types,
rather than trying to mark them FOR UPDATE. The actual error message now
only appears if you explicitly name the join in FOR UPDATE.
