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 4186CF99.8030103@mbigroup.it
Whole thread Raw
In response to Re: UPDATE is not allowed in a non-volatile function  (Tom Lane <tgl@sss.pgh.pa.us>)
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 good improvement but on the other side will
>>limit too much if I know what I'm doing.
> 
> 
> I've got zero sympathy for this argument.  It's been documented right
> along that functions with side-effects must be marked volatile.  You
> don't have a 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 nonvolatile function
> 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: Rod Taylor
Date:
Subject: Error: set log_error_verbosity to verbose fails
Next
From: Neil Conway
Date:
Subject: NoMovementScanDirection