From: | Joel Jacobson <joel(at)trustly(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL 1.2 |
Date: | 2014-09-04 09:22:41 |
Message-ID: | CAASwCXeJL=rVt0Vfc7=4E+YG86k+fZsCgiodDGxNjnXr+qD79A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 4, 2014 at 11:07 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> it is different semantic - returns composite or set of composites --- it is
> not row or rows
The point was, RETURNS returns 1 while RETURNS SETOF returns 0 .. n.
> Actually BL is usually processed oriented, so PL functions coverages changes
> in data, and for queries you use SELECT
OK, so you SELECT directly from tables?
And in the PLs you change a lot of rows in the same txn?
> Returning SET from function is less often - and usually it is not in
> preferred patterns because you can very simple block a optimizer.
Not if you do all access, also SELECT via PLs, then you might want to returns
lists of things based on some input.
But that's a different topic. What I wanted to examplify is the fact
we *already*
have a lot of syntax which handles the 1 row case in a special way.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-09-04 09:41:23 | Re: PL/pgSQL 1.2 |
Previous Message | Pavel Stehule | 2014-09-04 09:07:41 | Re: PL/pgSQL 1.2 |