('SELECT expression') inline, like macros, during the constant-folding
phase of planning. The actual expansion is not difficult, but checking
that we're not changing the semantics of the call turns out to be more
subtle than one might think; in particular must pay attention to
permissions issues, strictness, and volatility.
well as function calls. This is needed for cases where the planner has
constant-folded or inlined the original function call. Possibly we should
back-patch this change into 7.3 branch as well.
and eliminate its manual pfree() calls. This solves the encoding-conversion
bug recently reported, and should be faster and more robust than the
original coding anyway. For example, we are no longer at risk if
datatype output routines leak memory or choose to return a constant string.
logic, dissuade planner from thinking that 'x IS DISTINCT FROM 42' may
be optimized into 'x = 42' (!!), cause dependency on = operator to be
recorded correctly, minor other improvements.
instead of only one. This should speed up planning (only one hash path
to consider for a given pair of relations) as well as allow more effective
hashing, when there are multiple hashable joinclauses.
operations: make sure we use operators that are compatible, as determined
by a mergejoin link in pg_operator. Also, add code to planner to ensure
we don't try to use hashed grouping when the grouping operators aren't
marked hashable.
sublink results and COPY's domain constraint checking. A Const that
isn't really constant is just a Bad Idea(tm). Remove hacks in
parse_coerce and other places that were needed because of the former
klugery.
just done for copyfuncs/equalfuncs. Read functions in particular get
a lot shorter than before, and it's much easier to compare an out function
with the corresponding read function to make sure they agree.
initdb forced due to small changes in nodestring format (regularizing
a few cases that were formerly idiosyncratic).
