MIME-Version: 1.0
Date: Thu, 15 Jun 2023 10:16:12 -0400
From: chap@anastigmatix.net
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>,
 pgsql-hackers@lists.postgresql.org
Subject: Re: When IMMUTABLE is not.
In-Reply-To: <69234e25e34e68425f49630f79ef9991@anastigmatix.net>
References: <389c986d-fbb4-c644-9280-db7836af7ca9@postgrespro.ru>
 <2111925.1686835298@sss.pgh.pa.us>
 <69234e25e34e68425f49630f79ef9991@anastigmatix.net>
User-Agent: Roundcube Webmail/1.6.0
Message-ID: <4c32f84bc097dee0081e4cc3e733ef8d@anastigmatix.net>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/4c32f84bc097dee0081e4cc3e733ef8d%40anastigmatix.net>
Precedence: bulk

On 2023-06-15 09:58, chap@anastigmatix.net wrote:
> also influences what snapshot the
> function is looking at, and therefore what it can see, which has
> also struck me more as a tacked-on effect than something inherent
> in the declaration's meaning.

I just re-read that and realized I should anticipate the obvious
response "but how can it matter what the function can see, if
it's IMMUTABLE and depends on no data?".

So, I ran into the effect while working on PL/Java, where the
code of a function isn't all found in pg_proc.prosrc; that just
indicates what code has to be fetched from sqlj.jar_entry.

So one could take a strict view that "no PL/Java function should
ever be marked IMMUTABLE" because every one depends on fetching
something (once, at least).

But on the other hand, it would seem punctilious to say that
f(int x, int y) { return x + y; } isn't IMMUTABLE, only because
it depends on a fetch /of its own implementation/, and overall
its behavior is better described by marking it IMMUTABLE.

Regards,
-Chap