On Tue, Nov 22, 2016 at 4:15 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: >> The easiest thing to do might be to just enforce that all of the >> partition key columns have to be not-null when the range-partitioned >> table is defined, and reject any attempt to DROP NOT NULL on them >> later. That's probably better that shoehorning it into the table >> constraint. > > Agreed that forcing range partitioning columns to be NOT NULL during table > creation would be a better approach. But then we would have to reject > using expressions in the range partition key, right?
Why? > As a result, one change became necessary: to how we flag individual range > bound datum as infinite or not. Previously, it was a regular Boolean > value (either infinite or not) and to distinguish +infinity from > -infinity, we looked at whether the bound is lower or upper (the lower > flag). Now, instead, the variable holding the status of individual range > bound datum is set to a ternary value: RANGE_DATUM_FINITE (0), > RANGE_DATUM_NEG_INF (1), and RANGE_DATUM_POS_INF (2), which still fits in > a bool. You better not be using a bool to represent a ternary value! Use an enum for that -- or if in the system catalogs, a char. > Upon encountering an infinite range bound datum, whether it's > negative or positive infinity derives the comparison result. Consider the > following example: > > partition p1 from (1, unbounded) to (1, 1); > partition p2 from (1, 1) to (1, 10); > partition p3 from (1, 10) to (1, unbounded); > partition p4 from (2, unbounded) to (2, 1); > ... so on > > In this case, we need to be able to conclude, say, (1, -inf) < (1, 15) < > (1, +inf), so that tuple (1, 15) is assigned to the proper partition. Right. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
