Re: postgresql how to duplicate rows in result.

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

In response to

Responses

Browse pgsql-general by date

  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.