Re: When IMMUTABLE is not.

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: When IMMUTABLE is not.
Дата
Msg-id CAMsGm5fZWHTn4sugZ02ZaxBjPC88=Z9a3zF-mgTk6FHX_0zqxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: When IMMUTABLE is not.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: When IMMUTABLE is not.
Следующее
От: Jelte Fennema
Дата:
Сообщение: Re: run pgindent on a regular basis / scripted manner