Re: Relax requirement for INTO with SELECT in pl/pgsql - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Relax requirement for INTO with SELECT in pl/pgsql
Date
Msg-id CAHyXU0xFZnCEHBuFQyhLZj-hU3Ln0RQG6tqkz_Kj_ct3k4qDLw@mail.gmail.com
Whole thread Raw
In response to Re: Relax requirement for INTO with SELECT in pl/pgsql  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Wed, Mar 23, 2016 at 10:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 3/22/16 8:37 AM, Merlin Moncure wrote:
>>>
>>> I afraid of useless and forgotten call of functions. But the risk is same
>>> >like PERFORM - so this is valid from one half. The PERFORM statement
>>> > holds
>>> >special semantic, and it is interesting.
>>
>> I see your point here, but the cost of doing that far outweighs the
>> risks.  And I don't think the arbitrary standard of defining forcing
>> the user to identify if the query should return data is a good way of
>> identifying dead code.
>
> Not to mention that there's tons of other ways to introduce unintended
> inefficiencies. Off the top of my head, declaring variables that are never
> referenced and have no assignment is a big one.

Yes. This comes up most often with dblink for me.   Mainly because of
the slight wonkiness of dblink API, but totally agree this should
never have to be done.  Anyways, I submitted the patch to the next
open commit fest.

Totally off topic aside: are you in dallas for the next PUG? I
unfortunately missed the last one and will likely miss the next one
too -- I coach the company kickball team and we play on Wednesdays --
oh well.  Maybe beers afterwards?

merlin



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: WIP: Upper planner pathification
Next
From: Michael Meskes
Date:
Subject: Re: NOT EXIST for PREPARE