| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)yahoo(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PL/pgSQL PERFORM with CTE |
| Date: | 2013-08-23 18:13:54 |
| Message-ID: | CAHyXU0zVFP+ZDxg3nYbVEvRLVpf15ZzuqDW86cBzwX82gtzLVA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Pavel,
>
>> But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL
>> a unbound query is used to direct transfer data to client side.
>
> Are you planning to implement that in PL/pgSQL?
>
> Currently, PL/pgSQL requires RETURN ____ in order to return a query
> result to the caller. Is there some reason we'd change that?
>
> If you're implementing TSQL-for-PostgreSQL, of course you might want to
> have different behavior with SELECT. However, TSQL is not PL/pgSQL.
I don't think Pavel's point makes sense in the context of functions.
With stored procedures it might though -- but I don't see why that we
need to reserve behavior for SELECT without INTO -- it can behave
differently when executed with a hypothetical CALL.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-08-23 18:14:04 | Re: Behaviour of take over the synchronous replication |
| Previous Message | Fábio Telles Rodriguez | 2013-08-23 18:10:26 | Re: Performance problem in PLPgSQL |