Message-ID: <6828898d-5fe1-4709-816e-5cf606974227@gmail.com>
Date: Fri, 20 Sep 2024 10:46:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Volatile functions under Memoize node
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
 Richard Guo <guofenglinux@gmail.com>
References: <7ab4aac3-4790-416f-98b8-2ec0707cceb5@gmail.com>
 <CAApHDvopmkAOecfQczbOvkVvo=OK89rABXujVYsFevsk77Dqdw@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAApHDvopmkAOecfQczbOvkVvo=OK89rABXujVYsFevsk77Dqdw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6828898d-5fe1-4709-816e-5cf606974227%40gmail.com>
Precedence: bulk

On 20/9/2024 04:36, David Rowley wrote:
> On Fri, 20 Sept 2024 at 04:47, Andrei Lepikhov <lepihov@gmail.com> wrote:
> I'm not sure if it's a good idea to penalise your case when we're not
> all that consistent to start with.  Is this causing some sort of
> breakage?
I skimmed the code entries with such checks and found out that the 
initial reason was to avoid index scans, with a reason that such a 
routine should be applied to each tuple of the table.
The second reason - to postpone expression evaluation (9118d03) - is 
also reasonable for me. It was introduced to be consistent with the 
clause's syntactical level in the SQL.
It seems to follow the same idea as disabling subquery pull-ups: to 
avoid multiple evaluations and change the syntactical level.
At the same time, Material doesn't care about volatility. So, what was 
the idea behind the commit 990c365 you added?

-- 
regards, Andrei Lepikhov