Re: functions marked STABLE not allowed to do INSERT - Mailing list pgsql-hackers

From Tino Wildenhain
Subject Re: functions marked STABLE not allowed to do INSERT
Date
Msg-id 1132004288.7012.27.camel@Andrea.peacock.de
Whole thread Raw
In response to Re: functions marked STABLE not allowed to do INSERT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Am Montag, den 14.11.2005, 15:06 -0500 schrieb Tom Lane:
> Tino Wildenhain <tino@wildenhain.de> writes:
> > Now this is really a bug:
> 
> That's in the eye of the beholder (and one who wasn't paying attention
> to previous discussion of this point, evidently).

Yes I was, but only to the fact it is not useable for 
caching and there are some cases (like random) 
for which STABLE would be bad thing [tm].

> The reason why the no-data-change rule is now enforced, not only
> recommended, is that a stable/immutable function now actually would
> not see any changes it did make.  Consider code like
> 
>     INSERT INTO foo VALUES (42, ...);
>     SELECT * INTO rec FROM foo WHERE key = 42;
>     IF NOT FOUND THEN
>         RAISE EXCEPTION 'where did my row go?';
> 
> If this were allowed in stable/immutable functions, the RAISE would
> in fact be reached in 8.1, because the SELECT will be done with the
> snapshot of the query that called the function.  This is a feature,

Ah this was the missing bit. I though this would only be true
for IMMUTABLE.

Thanks for the explanation. I'm not fine w/ it.

Regards
Tino



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: 8.0 -> 8.1 dump duplicate key problem?
Next
From: Robert Treat
Date:
Subject: Re: functions marked STABLE not allowed to do INSERT