From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Understanding behavior of SELECT with multiple unnested columns |
Date: | 2013-03-29 14:24:35 |
Message-ID: | CAHyXU0w1ceGsLYZpfkr_Mt9UnK+nyiGKhUmJhRJ=0FTGP6-_pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Mar 27, 2013 at 9:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> writes:
>> The rule appears to be,
>> where N_x & N_y are the number of entries returned for x & y:
>> N_result = is the smallest positive integer that has N_x & N_y as factors.
>
> Right: if there are multiple set-returning functions in a SELECT list,
> the number of rows you get is the least common multiple of their
> periods. (See the logic in ExecTargetList that cycles the SRFs until
> they all report "done" at the same time.) I guess there's some value
> in this for the case where they all have the same period, but otherwise
> it's kind of bizarre. It's been like that since Berkeley days though,
> so I doubt we'll consider changing it now. Rather, it'll just be
> quietly deprecated in favor of putting SRFs into FROM (with LATERAL
> where needed).
It's a neat way to make a query that doesn't terminate (which AFAIK is
impossible in vanilla SQL):
create sequence s;
select generate_series(1,nextval('s')), generate_series(1,nextval('s'));
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Gavan Schneider | 2013-03-29 15:08:14 | Re: Money casting too liberal? |
Previous Message | Gavan Schneider | 2013-03-29 12:32:20 | Re: Money casting too liberal? |