Re: function side effects

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Tatsuo Ishii" <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: function side effects
Date: 2010-02-23 16:08:43
Message-ID: 22537.1266941323@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Those classifications are meant as planner directives; they are
>> NOT meant to be bulletproof. Hanging database integrity
>> guarantees on whether a "non volatile" function changes anything
>> is entirely unsafe. To give just one illustration of the
>> problems, a nonvolatile function is allowed to call a volatile
>> one.

> Could it work to store a flag in each process to indicate when it is
> executing a non-volatile function, and throw an error on any attempt
> to call a volatile function or modify the database?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-23 16:13:06 Re: [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous Message Alvaro Herrera 2010-02-23 16:08:16 Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)