Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
Date
Msg-id 1229467.1678555436@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17830: Incorrect memory access in trgm_regexp
Next
From: PG Bug reporting form
Date:
Subject: BUG #17832: ERROR: failed to apply nullingrels to a non-Var in HEAD