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
Heikki Linnakangas 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
> calling eval_const_expressions(): Ge
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 po
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 C
