Re: UPDATE is not allowed in a non-volatile function

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: UPDATE is not allowed in a non-volatile function
Date: 2004-11-02 00:09:08
Message-ID: 4186D024.5070601@bigfoot.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Gaetano Mendola <mendola(at)bigfoot(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-11-02 00:34:52 Path expansion in initdb
Previous Message Gaetano Mendola 2004-11-02 00:06:49 Re: UPDATE is not allowed in a non-volatile function