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
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? |