Re: UPDATE is not allowed in a non-volatile function - Mailing list pgsql-hackers

From Gaetano Mendola
Subject Re: UPDATE is not allowed in a non-volatile function
Date
Msg-id 4186D024.5070601@bigfoot.com
Whole thread Raw
In response to Re: UPDATE is not allowed in a non-volatile function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UPDATE is not allowed in a non-volatile function  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
Tom Lane wrote:
> Gaetano Mendola <mendola@bigfoot.com> writes:>>> The fact that a non-volatile function can not perform>> update is a
goodimprovement but on the other side will>> limit too much if I know what I'm doing.>>>> I've got zero sympathy for
thisargument.  It's been documented right> along that functions with side-effects must be marked volatile.  You> don't
havea lot of room to complain because 8.0 started to enforce that.
 

> In practice you can circumvent the restriction by splitting the> function in two (ie, there is no check that a
nonvolatilefunction> doesn't call any volatile functions).  So if you insist on sticking> with an unsafe application
design,you can do it with relatively> localized changes.
 


I do not consider my design as "unsafe", this is for example how a
cache works: expose a "read" without side effect but updating internal
statistics. After all the read will not alter the data that it expose
but other data that the user even don't know the existence.

However I think that "that missing check" is "unsafe" and jeopardize the
effort to avoid a wrong user design.

Having say that I'm happy to know that what I did will continue to work
splitting the function in two parts.

Regards
Gaetano Mendola








pgsql-hackers by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Re: [COMMITTERS] pgsql: timestamptz_trunc() should only
Next
From: Peter Eisentraut
Date:
Subject: Path expansion in initdb