| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
| Cc: | 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-27 14:03:12 |
| Message-ID: | 10348.1364392992@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2013-03-27 14:40:13 | Re: pltcl and modules question |
| Previous Message | Thomas Kellerer | 2013-03-27 08:54:03 | Re: Why does Postgres allow duplicate (FK) constraints |