Re: PL/pgSQL PERFORM with CTE - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: PL/pgSQL PERFORM with CTE
Date
Msg-id 3FC52969-6403-48AA-9A2A-A6A765CE5748@justatheory.com
Whole thread Raw
In response to Re: PL/pgSQL PERFORM with CTE  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: PL/pgSQL PERFORM with CTE  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Aug 27, 2013, at 1:36 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

> I agree with David that we should use some new syntax to specify
> return-results-directly-to-client, assuming we ever get any such
> functionality.  It seems like a pretty bad choice of default behavior,
> which is essentially what you're saying it should be.
>
> this functionality should be disabled in functions. This can be allowed only for procedures started by CALL
statements.I don't propose it for functions.  

That does not make it a bad idea. Let me summarize:

I propose to remove the requirement to use PERFORM to execute queries for which the result should be discarded. It
shouldinstead be implicit that results are discarded unless you capture them or return them. 

You propose to continue requiring PERFORM to execute queries for which the result should be discarded. This is so that,
inthe future, SQL statements can implicitly return to the caller. 

That sound about right to you?

I *really* dislike the idea that some SQL execution implicitly returns from a PL/pgSQL function or procedure. That just
seemstoo magical. I strongly prefer that the scope of the code executed in a function or procedure be limited to the
scopeof the function or procedure itself, and only return data to the caller if I explicitly tell it to. Much less
magical,IMHO. 

Best,

David




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: split postmaster's checkDataDir to src/common
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL PERFORM with CTE