Re: When IMMUTABLE is not. - Mailing list pgsql-hackers

From chap@anastigmatix.net
Subject Re: When IMMUTABLE is not.
Date
Msg-id 4c32f84bc097dee0081e4cc3e733ef8d@anastigmatix.net
Whole thread Raw
In response to Re: When IMMUTABLE is not.  (chap@anastigmatix.net)
Responses Re: When IMMUTABLE is not.
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: When IMMUTABLE is not.
Next
From: "David G. Johnston"
Date:
Subject: Re: When IMMUTABLE is not.