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
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 |