Re: Calculated view fields (8.1 != 8.2) - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Calculated view fields (8.1 != 8.2)
Date
Msg-id 45F17E6C.5070909@phlo.org
Whole thread Raw
In response to Re: Calculated view fields (8.1 != 8.2)  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Calculated view fields (8.1 != 8.2)  (Gaetano Mendola <gmendola@mbigroup.it>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Calculated view fields (8.1 != 8.2)
Next
From: "Florian G. Pflug"
Date:
Subject: Re: CLUSTER and MVCC