Hi,
Tom Lane wrote:
I don't agree with that at all. I can imagine plenty of situations
where a tuple falling outside the range of available partitions *should*
be treated as an error. For instance, consider timestamped observations
--- data in the future is certainly bogus, and data further back than
you want to deal with must be an entry error as well.
Isn't it better to have these constraints as table constraints, instead
of burying them in the partitioning definition? Mixing those two
concepts seems very wired to me.
Or am I missing any benefit of mixing them?
Regards
Markus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
