public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: David G. Johnston <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Yura Sokolov <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: When IMMUTABLE is not.
Date: Thu, 15 Jun 2023 10:49:01 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwbcsPwm_iiE8p5TYZ=2AEnt4LHpCnjjHYoCRAuZk9tzFw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAKFQuwbcsPwm_iiE8p5TYZ=2AEnt4LHpCnjjHYoCRAuZk9tzFw@mail.gmail.com>

"David G. Johnston" <[email protected]> writes:
> The failure to find and execute the function code itself is not a failure
> mode that these markers need be concerned with.  Assuming one can execute
> the function an immutable function will give the same answer for the same
> input for all time.

The viewpoint taken in the docs I mentioned is that an IMMUTABLE
marker is a promise from the user to the system about the behavior
of a function.  While the system does provide a few simple tools
to catch obvious errors and to make it easier to write functions
that obey such promises, it's mostly on the user to get it right.

In particular, we've never enforced that an immutable function can't
call non-immutable functions.  While that would seem like a good idea
in the abstract, we've intentionally not tried to do it.  (I'm pretty
sure there is more than one round of previous discussions of the point
in the archives, although locating relevant threads seems hard.)
One reason not to is that polymorphic functions have to be marked
with worst-case volatility labels.  There are plenty of examples of
functions that are stable for some input types and immutable for
others (array_to_string, for instance); but the marking system can't
represent that so we have to label them stable.  Enforcing that a
user-defined immutable function can't use such a function might
just break things for no gain.

			regards, tom lane

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: When IMMUTABLE is not.
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox