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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17827: Rule on insert into table doesn't work when excepting select from the table itself
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17830: Incorrect memory access in trgm_regexp