From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, Alessandro Baggi <alessandro(dot)baggi(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: postgresql how to duplicate rows in result. |
Date: | 2017-02-21 20:14:36 |
Message-ID: | CAHyXU0wU=g+fCSF9D8NpboeH=uaw7yOo=TzL2jCsQwCiGyQuDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 16, 2017 at 10:27 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> If it wasn't lateral the reference to number in "generate_series(1, number)"
> would fail.
huh -- I didn't know that! Testing it out, all JOIN types imply
LATERAL if the function call is tlist SRF style (which is pretty werid
IMO) I tend to avoid optional words (with the important exception of
AS for column list renames) but I think it's a good idea to disclose
LATERAL in this case. It's a big clue to the reader what is going on
and the expanded form:
SELECT foo.* FROM foo CROSS JOIN LATERAL (SELECT a,b FROM func(foo.bar)) q;
... requires LATERAL to be explicitly stated. This form is more
general since it can be cleanly used when func() returns more than one
column.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-02-21 20:46:12 | Re: Bad planning data resulting in OOM killing of postgres |
Previous Message | Alexey Lesovsky | 2017-02-21 18:54:10 | save PGresult to file. |