Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> There might be other options, but one way to solve this would be to
>> treat partition bounds as a general expression in the grammar and then
>> check in post-parse analysis that it's a constant.
> Yeah -- isn't the usual way of handling this to run the user's input
> through eval_const_expressions and see if the result is constant?
Not sure we want to go quite that far: at minimum it would imply invoking
arbitrary stuff during a utility statement, which we generally try to
avoid. Still, copy-from-query does that, so we can certainly make it
work if we wish.
Perhaps more useful to discuss: would that truly be the semantics we want,
or should we just evaluate the expression and have done? It's certainly
arguable that "IN (random())" ought to draw an error, not compute some
random value and use that. But if you are insistent on partition bounds
being immutable in any strong sense, you've already got problems, because
e.g. a timestamptz literal's interpretation isn't necessarily fixed.
It's only after we've reduced the original input to Datum form that we
can make any real promises about the value not moving. So I'm not seeing
where is the bright line between "IN ('today')" and "IN (random())".
regards, tom lane