Re: BUG #17976: Inconsistent results of SELECT using CASE WHEN clause
От | Tom Lane |
---|---|
Тема | Re: BUG #17976: Inconsistent results of SELECT using CASE WHEN clause |
Дата | |
Msg-id | 2256362.1686857757@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17976: Inconsistent results of SELECT using CASE WHEN clause (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: BUG #17976: Inconsistent results of SELECT using CASE WHEN clause
|
Список | pgsql-bugs |
Richard Guo <guofenglinux@gmail.com> writes: > I went ahead and drafted a patch as attached. But I'm not sure if it > suffices to only update ec_relids, em_relids and ec_sources as the patch > does. Also I'm wondering if any of them would become empty after the > update. Thanks. I pushed this after making some changes: * I'm not convinced that it's safe to update only the ECs listed in the baserel's eclass_indexes; that would miss any ECs that mention only the outer join's relid and not the baserel's. Perhaps that's impossible but I don't feel comfortable about it. It shouldn't cost much more to just scan the whole eq_classes list here. * I pushed the update into a separate function for cosmetic reasons (mostly to make it easy to add comments similar to those for remove_rel_from_restrictinfo). * I added logic to remove dead EquivalenceMembers entirely. This is partly to make sure we don't generate bogus joinclauses using them, but mostly to save cycles in later examinations of the EC. * To be on the safe side I made it clear the ec_derived lists. We shouldn't really need whatever is in there anymore anyway, so it's probably not worth fixing those RestrictInfos. I noticed in testing that this frequently makes the whole EquivalenceClass a dead letter (with 0 or 1 surviving member), but sadly we can't remove it from eq_classes unless we want to rebuild all the eclass_indexes sets. Probably not worth it. regards, tom lane
В списке pgsql-bugs по дате отправления: