On Tue, Jun 13, 2017 at 10:24 AM, Robert Haas <robertmh...@gmail.com> wrote: > I think that's going to come as an unpleasant surprise to more than > one user. I'm not sure exactly how we need to restructure things here > so that this works properly, and maybe modifying > predicate_implied_by() isn't the right thing at all; for instance, > there's also predicate_refuted_by(), which maybe could be used in some > way (inject NOT?). But I don't much like the idea that you copy and > paste the partitioning constraint into a CHECK constraint and that > doesn't work. That's not cool.
OK, I think I see the problem here. predicate_implied_by() and predicate_refuted_by() differ in what they assume about the predicate evaluating to NULL, but both of them assume that if the clause evaluates to NULL, that's equivalent to false. So there's actually no option to get the behavior we want here, which is to treat both operands using CHECK-semantics (null is true) rather than WHERE-semantics (null is false). Given that, Ashutosh's proposal of passing an additional flag to predicate_implied_by() seems like the best option. Here's a patch implementing that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
extend-predicate-implied-by-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
