-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>> 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
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> 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
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 hav
Florian G. Pflug wrote:
> Gaetano Mendola 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 t
Gaetano Mendola 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
mi
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 reco
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 usu
Martijn van Oosterhout writes:
> 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.
Volatile functions that are not at the top level of a query are *always*
going t
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gaetano Mendola wrote:
> Tom Lane wrote:
>> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>> [ 8.2 evaluates volatile functions in the targetlist of a view ]
>>> If I mark the function as STABLE or IMMUTABLE then even with version
>>> 8.2 the function i
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>> [ 8.2 evaluates volatile functions in the targetlist of a view ]
>> If I mark the function as STABLE or IMMUTABLE then even with version
>> 8.2 the function is not evaluated. Is this the intended behavior?
>
> Yes; people complained
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> [ 8.2 evaluates volatile functions in the targetlist of a view ]
> If I mark the function as STABLE or IMMUTABLE then even with version
> 8.2 the function is not evaluated. Is this the intended behavior?
Yes; people complained that we needed to be more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm observing this behavior in 8.2:
kalman=# create table test ( a integer, b integer );
CREATE TABLE
kalman=#
kalman=# CREATE OR REPLACE FUNCTION sp_test ( INTEGER )
kalman-# RETURNS INTEGER AS'
kalman'# DECLARE
kalman'#a_id_contract
13 matches
Mail list logo