MIME-Version: 1.0
References: <389c986d-fbb4-c644-9280-db7836af7ca9@postgrespro.ru>
 <2111925.1686835298@sss.pgh.pa.us> <69234e25e34e68425f49630f79ef9991@anastigmatix.net>
 <4c32f84bc097dee0081e4cc3e733ef8d@anastigmatix.net> <CAKFQuwbcsPwm_iiE8p5TYZ=2AEnt4LHpCnjjHYoCRAuZk9tzFw@mail.gmail.com>
 <2131668.1686840541@sss.pgh.pa.us>
In-Reply-To: <2131668.1686840541@sss.pgh.pa.us>
From: Isaac Morland <isaac.morland@gmail.com>
Date: Thu, 15 Jun 2023 10:55:01 -0400
Message-ID: <CAMsGm5fZWHTn4sugZ02ZaxBjPC88=Z9a3zF-mgTk6FHX_0zqxA@mail.gmail.com>
Subject: Re: When IMMUTABLE is not.
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, 
	"chap@anastigmatix.net" <chap@anastigmatix.net>, Yura Sokolov <y.sokolov@postgrespro.ru>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000006a119f05fe2c4181"
Archived-At: <https://www.postgresql.org/message-id/CAMsGm5fZWHTn4sugZ02ZaxBjPC88%3DZ9a3zF-mgTk6FHX_0zqxA%40mail.gmail.com>
Precedence: bulk

--0000000000006a119f05fe2c4181
Content-Type: text/plain; charset="UTF-8"

On Thu, 15 Jun 2023 at 10:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.
>

More sophisticated type systems (which I am *not* volunteering to graft
onto Postgres) can handle some of this, but even Haskell has
unsafePerformIO. The current policy is both wise and practical.

--0000000000006a119f05fe2c4181
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, 15 Jun 2023 at 10:49, Tom Lane &l=
t;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
In particular, we&#39;ve never enforced that an immutable function can&#39;=
t<br>
call non-immutable functions.=C2=A0 While that would seem like a good idea<=
br>
in the abstract, we&#39;ve intentionally not tried to do it.=C2=A0 (I&#39;m=
 pretty<br>
sure there is more than one round of previous discussions of the point<br>
in the archives, although locating relevant threads seems hard.)<br>
One reason not to is that polymorphic functions have to be marked<br>
with worst-case volatility labels.=C2=A0 There are plenty of examples of<br=
>
functions that are stable for some input types and immutable for<br>
others (array_to_string, for instance); but the marking system can&#39;t<br=
>
represent that so we have to label them stable.=C2=A0 Enforcing that a<br>
user-defined immutable function can&#39;t use such a function might<br>
just break things for no gain.<br></blockquote><div><br></div><div>More sop=
histicated type systems (which I am *not* volunteering to graft onto Postgr=
es) can handle some of this, but even Haskell has unsafePerformIO. The curr=
ent policy is both wise and practical.</div></div></div>

--0000000000006a119f05fe2c4181--