Florian G. Pflug wrote:
> 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.
Well some function are volatile and can not be marked as stable.
We develop our applications layering the modules, we didn't have any reason
to forbid as "coding rule" to put function call on view in low level layers.
After all views are there also to build up your schema layering the info.
I can immagine a case when a lower module exports a view to upper layer stating
the interface as list of fields:
first_name, last_name, ....
with an *hidden* field that is a function call that updates the statistics on
how many time a given record was selected, then this technique can not be used
anymore starting with 8.2.x.
The above is not my case but it can be a possible scenario (I admit not a sane
one ).
Regards
Gaetano Mendola