Re: BUG #19649: Qual pushdown into GROUP BY subqueries ignores non-equivalence-preserving references to grouping col

сб, 5 сент. 2026 г. в 21:23, Andrei Lepikhov <lepihov(at)gmail(dot)com>:

> My concern is with the approach, not the code itself. The key change in v4
> is a
> single line:
>
> if (getBaseType(var->vartype) != JSONBOID)
> return false;
>
> This only addresses the specific type mentioned in the report. However, the
> reporter could have demonstrated the same bug using numeric, without
> involving
> jsonb at all. The same goes for float8. In core, the default btree
> opclasses
> that make no image-equality promise are numeric, float8, interval, jsonb,
> record
> and tsvector, among others.
>

I agree, I deliberately didn't include them. I didn't like the code I ended
up with when I took them into account. And I couldn't figure out a better
way to do it, so I just stuck with jsonb.

>
> The property we need is already in the catalogue. Peter and Anastasia added
> equalimage support functions in 612a1ab7672 for btree deduplication, and
> the
> documented contract is exactly what we need. If that holds, no wrapping
> expression can distinguish values that the grouping merged, whatever the
> wrapper is.
>
>
Regarding BTEQUALIMAGE_PROC, I agree as well — I also considered it, but
rejected it because I thought it would degrade the execution plan, although
in our case it's actually a perfect fit.

> The second is to declare the result unspecified [1]. SQLite reproduces our
> bug
> through type affinity, and their answer is that the affinity of such a
> column is
> indeterminate and the group representative is arbitrary, so any result is
> legal.
> Some discussions in the Internet give me an idea that SQL Server restrict
> clause
> pushdown in such cases.
>
> I personally prefer the second approach, possibly with an image equality
> check.
> GROUP BY already hands back an arbitrary member of the group. Postgres
> does not
> promise which one, and any expression that can distinguish members of the
> class
> is therefore reading something we never guaranteed.
>
> [1] https://sqlite.org/forum/info/6dc048f81303cb97
>
>
>
I'll take a look at the code from [0].

Perhaps we will be able to find some option in the discussion process and I
will try to implement it.

--
Regards,
Rachitskiy Andrey