On Thu, Dec 1, 2016 at 12:48 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Nov 25, 2016 at 5:49 AM, Amit Langote 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.
Yeah, I thought so too. >> 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. The latest patch I posted earlier today has this implementation. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
