Re: function side effects

> IMMUTABLE/STABLE/VOLATILE is not really about side effects, it is about
> how long the function value can be expected to hold still for.
>
> There are quite a lot of cases of functions that are marked
> conservatively as stable (or even volatile) but could be considered
> immutable in particular queries, because the application developer is
> prepared to assume that values such as GUCs won't change in his usage.
> The traditional way to deal with that is to wrap them in an immutable
> wrapper function. There's actually code in the planner to make that
> work --- we have to suppress inlining to avoid exposing the not-immutable
> guts, else the planner will not do what's wanted.

"IMMUTABLE indicates that the function cannot modify the database..."

"STABLE indicates that the function cannot modify the database..."

Apparently IMMUTABLE/STABLE should not write to database according to
docs. Are you saying that in the real world these are ignored? If so,
this is an important database intergrity issue as Simon pointed out.

> It's *not an error* for a nonvolatile function to call a volatile one.
> At least it's never been in the past, and I'm sure you'd break some
> applications if you made it so in the future.

If this is true, at least the docs should be corrected IMO.

> There may be some value in inventing a "has no side effects" marker, but
> that should not be confused with IMMUTABLE/STABLE.

It seems it is neccessary to invent new marker for not only pgpool but
HOT/SR (and may be Slony). They need to know if a query including
functions do writes or not *before* sending to backend. Otherwise they
got error because they sent a write query to standby.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp