From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: postgresql@juneidy.wibowo.au, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19377: Query planner interesting behaviour
In-reply-to: 
 <CAApHDvpbmPJbJsaKEicYD345cy4jXtW7Egrc+WLnhj8Mnwrddg@mail.gmail.com>
References: <19377-6797bfc0a06bf23c@postgresql.org>
 <CAApHDvpbmPJbJsaKEicYD345cy4jXtW7Egrc+WLnhj8Mnwrddg@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Wed, 21 Jan 2026 21:06:51 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2212448.1769012325.1@sss.pgh.pa.us>
Date: Wed, 21 Jan 2026 11:18:45 -0500
Message-ID: <2212449.1769012325@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2212449.1769012325%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 13 Jan 2026 at 21:57, PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> It's weird that in the first query postgres doesn't seem to treat
>> st_makevalid($0) as a constant and I think re-evaluate st_makevalue($0) for
>> every row. Is that an expected behaviour?

> Yes, it's expected. We don't do anything special to try and walk up
> function call chains of immutable functions for init plan parameters
> to push function calls down to the init plan. Perhaps something is
> possible here, but anyone proposing we change this would need to come
> armed with proof that it's safe to do this.

It would be a fairly hard sell, I think, because traditionally
PG users have understood that a scalar sub-SELECT like this is an
optimization fence.  Pushing stuff across that fence is likely to
break some hand-optimized queries.

			regards, tom lane