Re: Teach predtest about IS [NOT] proofs
От | James Coleman |
---|---|
Тема | Re: Teach predtest about IS [NOT] |
Дата | |
Msg-id | CAAaqYe9Cs6RttpMo1x0MdJKV9wxYJC5iknE6S7+5+dtY7q25Pg@mail.gmail.com обсуждение исходный текст |
Ответ на |
Re: Teach predtest about IS [NOT] |
Ответы |
Re: Teach predtest about IS [NOT] |
Список | pgsql-hackers |
On Mon, Mar 25, 2024 at 5:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > James Coleman <jtc331@gmail.com> writes: > > [ v6 patchset ] > > I went ahead and committed 0001 after one more round of review > > statements; my bad). I also added the changes in test_predtest.c from > 0002. I attach a rebased version of 0002, as well as 0003 which isn't > changed, mainly to keep the cfbot happy. > > I'm still not happy with what you did in predicate_refuted_by_recurse: > it feels wrong and rather expensively so. There has to be a better > way. Maybe strong vs. weak isn't quite the right formulation for > refutation tests? Possibly. Earlier I'd mused that: > Alternatively (to avoid unnecessary CPU burn) we could modify > predicate_implied_by_recurse (and functionals called by it) to have a > argument beyond "weak = true/false" Ie.g., an enum that allows for > something like "WEAK", "STRONG", and "EITHER". That's a bigger change, > so I didn't want to do that right away unless there was agreement on > that direction. I'm going to try implementing that and see how I feel about what it looks like in practice. Regards, James Coleman
В списке pgsql-hackers по дате отправления: