Re: Why overhead of SPI is so large?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why overhead of SPI is so large?
Дата
Msg-id 26173.1574453469@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why overhead of SPI is so large?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in
>> a) we allow to call volatile functions from nonvolatile (stable, immutable)
>> that really does write
>> b) but this change is not visible in parent nonvolatile functions. Is
>> visible only in volatile functions.
>>
>> Is it expected behave?

> I'm not sure, volatility is the total bahavior of the function,
> regardless of whatever the function does internally. Even though I'm
> not sure how to use volatile functions in non-volatile functions, I
> don't see direct reason or how to inhibit that and I think we don't
> even need to bother that. It's owe to the definier of the function.

I'm pretty sure we had this discussion long ago when we implemented
the existing read-only-function restrictions in plpgsql.  Yeah, in
principle an immutable function should refuse to call non-immutable
functions, but the practical costs and benefits of doing that aren't
very attractive.  The existing rules are inexpensive to enforce and
catch most mistakes in this area.  Catching the other few percent of
mistakes would require a really significant change, not only on our
part but also users' parts --- for example, forgetting to label a
function as immutable when it could be might break your application
entirely.

I made some cosmetic fixes in the proposed patch and pushed it.

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [PATCH][BUG FIX] Pointer arithmetic with NULL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TAP tests aren't using the magic words for Windows file access