Robert Haas <robertmh...@gmail.com> writes: > On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut > <peter.eisentr...@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