From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: function side effects |
Date: | 2010-02-23 19:02:58 |
Message-ID: | 424.1266951778@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> I didn't realize tsearch functions were volatile. Should they
>> really be so?
> Uhm, my mistake. They're stable.
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.
There may be some value in inventing a "has no side effects" marker, but
that should not be confused with IMMUTABLE/STABLE.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-02-23 19:19:51 | Re: [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server |
Previous Message | Simon Riggs | 2010-02-23 18:58:22 | Re: pg_stop_backup does not complete |