Re: PL/pgSQL PERFORM with CTE

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Jan Wieck <JanWieck(at)yahoo(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL PERFORM with CTE
Date: 2013-08-28 00:30:03
Message-ID: 521D448B.80308@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/28/2013 12:10 AM, Pavel Stehule wrote:
>
>
> so if I write on client side
>
> BEGIN;
> SELECT 1,2;
> SELECT 2;
> SELECT 3,4;
> END;
>
> then I expect results
>
> 1,2
> 2
> 3,4
And you are perfectly ok to discard the results
Actually it would be much more helpful to have
"discard the results" syntax from client side, as
in this case they take up network resources.
>
> Procedure is some batch moved and wrapped on server side
>
> CREATE PROCEDURE foo()
> BEGIN
> SELECT 1,2;
> SELECT 2;
> SELECT 3,4
> END;
>
> And is not strange expect a result
>
> CALL foo()
>
> 1,2
> 2
> 3,4
>
> Procedure is a script (batch) moved to server side for better
> performance and better reuse.
And you are perfectly ok to discard the results here as well

In a function I do expect the result from select but I also
expect that I can silently ignore the result.

> My proposal is consistent - no result goes to /dev/null without
> special mark. It is disabled (in function) or it goes to client (in
> procedures).
So you can ignore the result in a procedure (by just skipping / not
assigning it on client) but not in a function ?

Can you point out some other languages which *require* you
to store the result of a function call or have a special syntax/keyword
when you do not want to store it ?

Cheer

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sawada Masahiko 2013-08-28 01:28:04 Re: Behaviour of take over the synchronous replication
Previous Message David E. Wheeler 2013-08-27 22:22:04 Re: PL/pgSQL PERFORM with CTE