On Mon, Dec 15, 2014 at 6:55 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Robert wrote:
>> On Sun, Dec 14, 2014 at 9:12 PM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> > This means if a user puts arbitrary expressions in a partition definition, say,
>> >
>> > ... FOR VALUES extract(month from current_date) TO extract(month from
>> current_date + interval '3 months'),
>> >
>> > we make sure that those expressions are pre-computed to literal values.
>>
>> I would expect that to fail, just as it would fail if you tried to
>> build an index using a volatile expression.
>
> Oops, wrong example, sorry. In case of an otherwise good expression?
I'm not really sure what you are getting here. An "otherwise-good
expression" basically means a constant. Index expressions have to be
things that always produce the same result given the same input,
because otherwise you might get a different result when searching the
index than you did when building it, and then you would fail to find
keys that are actually present. In the same way, partition boundaries
also need to be constants. Maybe you could allow expressions that can
be constant-folded, but that's about it. If you allow anything else,
then the partition boundary might "move" once it's been established
and then some of the data will be in the wrong partition.
What possible use case is there for defining partitions with
non-constant boundaries?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company