Re: Bug? Function with side effects not evaluated in CTE

From: John R Pierce <pierce(at)hogranch(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Bug? Function with side effects not evaluated in CTE
Date: 2013-10-21 23:02:51
Message-ID: 5265B29B.6060406@hogranch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 10/21/2013 3:52 PM, BladeOfLight16 wrote:
> I've only skimmed this thread, but clearly, this is why using
> functions with side effects in the middle of complex queries is a bad
> idea. =) Something like SELECT func_with_side_effect(1); is probably
> fine, but beyond that, put the function in the middle of a DO block or
> something and actually code what you want to happen.
>
> In terms of "expected" or "surprising" behavior, I don't think you can
> say ANY behavior could be expected. SQL is designed to be declarative.
> When it comes to retrieval (which is the issue originally raised since
> this involves a SELECT before the modification), you tell it what you
> want, and some engine figures out the best way to retrieve it. The
> engine is allowed to make whatever optimizations it chooses as long as
> the result set is correct. So if you really want to modify something,
> be explicit and don't drop a function with side effects in the middle
> of a complex query like this. God only knows what the engine will do
> with that.

indeed. ran into someone who was calling pg_stop_backup() deep in a
heavily nested query+function call mess, totally blew my mind why anyone
would think that was a good idea.

--
john r pierce 37N 122W
somewhere on the middle of the left coast

In response to

Browse pgsql-general by date

  From Date Subject
Next Message AI Rumman 2013-10-21 23:32:00 how to get the connected session pointer ( Archive * AH)
Previous Message BladeOfLight16 2013-10-21 22:52:42 Re: Bug? Function with side effects not evaluated in CTE