On Fri, Nov 25, 2016 at 5:49 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2016/11/25 11:44, Robert Haas wrote: >> On Thu, Nov 24, 2016 at 6:13 AM, Amit Langote wrote: >>> Also, it does nothing to help the undesirable situation that one can >>> insert a row with a null partition key (expression) into any of the range >>> partitions if targeted directly, because of how ExecQual() handles >>> nullable constraint expressions (treats null value as satisfying the >>> partition constraint). >> >> That's going to have to be fixed somehow. How bad would it be if we >> passed ExecQual's third argument as false for partition constraints? >> Or else you could generate the actual constraint as expr IS NOT NULL >> AND expr >= lb AND expr < ub. > > About the former, I think that might work. If a column is NULL, it would > be caught in ExecConstraints() even before ExecQual() is called, because > of the NOT NULL constraint. If an expression is NULL, or for some reason, > the partitioning operator (=, >=, or <) returned NULL even for a non-NULL > column or expression, then ExecQual() would fail if we passed false for > resultForNull. Not sure if that would be violating the SQL specification > though.
I don't think the SQL specification can have anything to say about an implicit constraint generated as an implementation detail of our partitioning implementation. > The latter would work too. But I guess we would only emit expr IS NOT > NULL, not column IS NOT NULL, because columns are covered by NOT NULL > constraints. 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