Re: Calculated view fields (8.1 != 8.2)

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: Calculated view fields (8.1 != 8.2)
Дата
Msg-id 45F17E6C.5070909@phlo.org
обсуждение исходный текст
Ответ на Re: Calculated view fields (8.1 != 8.2)  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Calculated view fields (8.1 != 8.2)  (Gaetano Mendola <gmendola@mbigroup.it>)
Список pgsql-hackers
Martijn van Oosterhout wrote:
> On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
>> Is really this what we want? I did a migration 8.0.x => 8.2.3 and I had on first hour of service up
>> lot of queries "blocked" due to this, consider in my case I have on v_ta milions of records and usually
>> that join extracts 1 row. Is there a way to set till I don't check all my huge schema to disable this
>> behaviour?
> 
> Most people figured it was a improvment. It's configured per function
> now, which wasn't the case before. I dont't think there was ever any
> discussion about having a global switch.

If your function is already marked immutable or stable, then nothing changes for 
you. If you *did* call volatile functions inside your select, then you now get
consistens behaviour. Since you don't want your function to be evaluated in all
cases, I assume that it shouldn't be marked volatile in the first place.

I think a lot of people forget to mark their functions volatile/stable/immutable
correctly, or don't know about the implications of these flags.

Maybe there should be a guc force_explicit_sideeffeect_declaration (defaulting
to on) which makes specifying either volatile, stable or immutable mandatory.
Then people would (hopefully) read the relevant part of the docs before
creating a function, and probably get the declaration right in the first place.

greetings, Florian Pflug


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Calculated view fields (8.1 != 8.2)
Следующее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: CLUSTER and MVCC