Re: Bug? Function with side effects not evaluated in CTE - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Bug? Function with side effects not evaluated in CTE
Date
Msg-id CAHyXU0xyRv6oinnADHPWt5cPXzrGYtR76jCwT5HE4FSqC-PjMw@mail.gmail.com
Whole thread Raw
In response to Re: Bug? Function with side effects not evaluated in CTE  (David Johnston <polobo@yahoo.com>)
Responses Re: Bug? Function with side effects not evaluated in CTE  (David Johnston <polobo@yahoo.com>)
List pgsql-general
On Fri, Oct 18, 2013 at 4:08 PM, David Johnston <polobo@yahoo.com> wrote:
> And why is volatile so special here?  A stable function seems just as good a
> candidate for this behavior and even an immutable one.

Absolutely disagree with this.  Stable operations do not have side
effects and volatile operations do (or at least they can).  Point
being: after the query runs the database is in the same state
regardless if a stable function is run or not.  So, for stable
operations (which covers most queries), the current behavior is good.
But, it's a completely different story in the case of volatile
expression and that's why I believe the optimization to skip is
plainly a POLA violation.  OP is not the first to bring it up by the
way.

> Wrapping INSERT/UPDATE/DELETE inside a non-procedural function is not that
> common and in those cases where it is used it is most often a standalone API

I'm not buying this either.  It may not be 'common' but people are
clearly exercising the behavior and 'data modifying with' is IMNSHO a
much better coding paradigm than functions wrapping same.
Regardless, the point at hand is whether specific plan semantics down
the chain can control whether or not volatile expressions should run.
Clearly, at least to me, they should not.

merlin


pgsql-general by date:

Previous
From: David Johnston
Date:
Subject: Re: Bug? Function with side effects not evaluated in CTE
Next
From: Anson Abraham
Date:
Subject: streaming replication: could not receive data from client: Connection reset by peer