I wrote:
I'd prefer not to have ExecPrepareExpr do it, though; that's supposed
to be working from a read-only expression tree supplied by the caller.
(The fix_opfuncids call in it is already pushing the bounds of that
concept.)
From a structural point of view the right thing would be to
Some further reflection about Rushabh Lathia's bug report of yesterday
led me to the realization that there's a pretty big hole in the function
defaults patch. Since we add default values during planning, it doesn't
work for any expression that's not fed through the planner. For
instance, ALTER
Tom Lane wrote:
The minimum-code-change solution would be to run around and try to make
sure every such expression gets passed through eval_const_expressions()
before we try to execute it. This is probably doable (looking for calls
to fix_opfuncids would be a good guide) but it seems like the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That seems ok to me. Calling eval_const_expressions() in ALTER COLUMN
and elsewhere is a good idea for performance reasons as well.
Yeah, probably so.
I can only find one more call to fix_opfuncids, where we're not already
