Re: Wrong unsafe-flag test in check_output_expressions()

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong unsafe-flag test in check_output_expressions()
Date: 2026-06-02 22:13:03
Message-ID: CAMbWs4-i6t1LGnQ-hNYSQ3eBZ9GgEa+Cuzt-T-AB4bKgT0tKaQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 3, 2026 at 5:59 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Mon, 1 Jun 2026 at 20:27, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > I happened to notice $subject when working on a bug-fix near-by.
> >
> > /* If subquery uses window functions, check point 4 */
> > if (subquery->hasWindowFuncs &&
> > (safetyInfo->unsafeFlags[tle->resno] &
> > UNSAFE_NOTIN_DISTINCTON_CLAUSE) == 0 &&
> > !targetIsInAllPartitionLists(tle, subquery))
> > {
> > /* not present in all PARTITION BY clauses, so mark it unsafe */
> > safetyInfo->unsafeFlags[tle->resno] |= UNSAFE_NOTIN_PARTITIONBY_CLAUSE;
> > continue;
> > }

> Yes, that's not intentional. Your proposed fix looks correct. Are you
> happy to go ahead with pushing and backpatching that?

Thanks for taking a look. Yeah, I'm happy to push that. I'm kind of
unsure whether this needs to be back-patched, since it doesn't lead to
wrong plans, so it isn't a live bug in practice.

> Wondering, did you spot that with eyes or tool assist?

For this one, I spotted it with eyeballs, when I was working on
another patch that fixes qual pushdown past window functions (and
other grouping layers) with mismatched opfamily/collation.

- Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-06-02 22:14:21 Re: Row pattern recognition
Previous Message Nathan Bossart 2026-06-02 22:11:52 Re: alert clients when prepared statements are deallocated