Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
От | David Rowley |
---|---|
Тема | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c |
Дата | |
Msg-id | CAApHDvoGAu9rY4iO0R+DZVxPck_M3015WUL_34XOhi9ygxYfnA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
|
Список | pgsql-bugs |
On Fri, 10 Mar 2023 at 05:09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In other words, after qual_is_pushdown_safe has rejected a qual as being > unsafe to push down, check_and_push_window_quals merrily does it anyway, > apparently on the theory that window functions are exempt from all rules. > How is this even a little bit sane? I don't think it is. I've not looked in detail yet, but I think we might be able to do something in check_output_expressions() so that we track the targetIsInAllPartitionLists() separately. Maybe unsafeColumns[] needs to become an enum type that has UNSAFE, SAFE, WINDOW_RUNCONDITION_ONLY and then change things so we never make a runCondition when the qual is UNSAFE. Anyway, I'll give it more thought and aim to come up with a patch early next week. David
В списке pgsql-bugs по дате отправления: