| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "chap(at)anastigmatix(dot)net" <chap(at)anastigmatix(dot)net>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: When IMMUTABLE is not. |
| Date: | 2023-06-15 14:55:01 |
| Message-ID: | CAMsGm5fZWHTn4sugZ02ZaxBjPC88=Z9a3zF-mgTk6FHX_0zqxA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 15 Jun 2023 at 10:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema | 2023-06-15 15:26:58 | Re: run pgindent on a regular basis / scripted manner |
| Previous Message | Tom Lane | 2023-06-15 14:49:01 | Re: When IMMUTABLE is not. |