Re: functions marked STABLE not allowed to do INSERT

From: Tino Wildenhain <tino(at)wildenhain(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions marked STABLE not allowed to do INSERT
Date: 2005-11-14 21:38:08
Message-ID: 1132004288.7012.27.camel@Andrea.peacock.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Am Montag, den 14.11.2005, 15:06 -0500 schrieb Tom Lane:
> Tino Wildenhain <tino(at)wildenhain(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2005-11-14 21:58:51 Re: functions marked STABLE not allowed to do INSERT
Previous Message Merlin Moncure 2005-11-14 20:43:20 Re: 8.0 -> 8.1 dump duplicate key problem?