Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> 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 functi
Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
>
>>The Rationale for my opinion is that since there is a need to accomplish
>>what Gaetano needs, there should be declarative power to express it and
>>thus, prevent "unsafe" designs. We need a way to declare a function
>>"stable with n
Robert,
I think the guidelines are fairly clear on what types of functions should be
declared with which types. But the key is that these are guidelines, not hard
and fast rules, since there may be times when you need to ignore them.
In 7.4 they where indeed guidelines. In 8.x the semantics o
On Wednesday 03 November 2004 18:06, Thomas Hallgren wrote:
> Tom,
>
> >What you think is non-intrusive may not be so at the database's level.
>
> I know. But thats not my point. Look at this this way:
>
> I'd like to declare a function STABLE. And I'd like to trust that
> declaration 100%. So a st
Tom,
What you think is non-intrusive may not be so at the database's level.
I know. But thats not my point. Look at this this way:
I'd like to declare a function STABLE. And I'd like to trust that
declaration 100%. So a stable function must *never* call a function that
is VOLATILE. Not directl
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> The Rationale for my opinion is that since there is a need to accomplish
> what Gaetano needs, there should be declarative power to express it and
> thus, prevent "unsafe" designs. We need a way to declare a function
> "stable with no _intrusive_ sid
Josh Berkus wrote:
Gaetano,
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.
A
Gaetano,
> 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.
At issue is
Gaetano,
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 "
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> 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 rig
Gaetano Mendola <[EMAIL PROTECTED]> 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 s
Hi all,
I missed the discussion on hacker about this, and
I'd like to give my HO.
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 did a sort of Lookup framework and this is extensively
used in m
12 matches
Mail list logo