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)
|
Список | 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 по дате отправления: