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

From Pavel Stehule
Subject Re: PL/pgSQL PERFORM with CTE
Date
Msg-id CAFj8pRCcpSANqUDfZx3M5xf42N=EVH=Zz4+keoA_wDHPOamARA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL PERFORM with CTE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/pgSQL PERFORM with CTE  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers



2013/8/27 Tom Lane <tgl@sss.pgh.pa.us>
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2013/8/27 David E. Wheeler <david@justatheory.com>
>> But whatever the keyword, I think it makes sense to require one to return
>> results to the caller. Any query that does not return, yield, or capture
>> (select into) values should just have its results discarded.

> A usual and first solution and syntax is defined by Sybase - we can define
> own syntax, but I don't think so it is necessary be original everywhere.
> My opinion is surely subjective - this feature is one from few features
> that are nice on T-SQL.

We aren't following T-SQL on any other syntax detail, so why would we
start with this one?  plpgsql is meant to follow Oracle syntax not T-SQL.

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.

Regards

Pavel
 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: pg_restore multiple --function options
Next
From: Kevin Grittner
Date:
Subject: Re: Behaviour of take over the synchronous replication