Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
От | Tom Lane |
---|---|
Тема | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c |
Дата | |
Msg-id | 1229467.1678555436@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
|
Список | pgsql-bugs |
David Rowley <dgrowleyml@gmail.com> writes: > On Fri, 10 Mar 2023 at 05:09, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. Why can't we simply *remove* all this logic from subquery pushdown? I would expect that what happens in useful cases is that we push down the (safe) qual and then during planning of the subquery we see a WHERE clause matching the window run condition and work with that. So this all seems redundant, quite aside from being faulty. regards, tom lane
В списке pgsql-bugs по дате отправления: