From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Date: | 2017-01-18 23:27:53 |
Message-ID: | CAKFQuwY+G97xii4F_2ZxSFxN0CTYDWeXFp3BiB_Cb7aGgmSFdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 18, 2017 at 4:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > I'll try to write something about the SRF-in-CASE issue too. Seeing
> > whether we can document that adequately seems like an important part
> > of making the decision about whether we need to block it.
>
> Here's what I came up with:
>
> This behavior also means that set-returning functions will be evaluated
> even when it might appear that they should be skipped because of a
> conditional-evaluation construct, such as CASE or COALESCE. For example,
> consider
>
> SELECT x, CASE WHEN x > 0 THEN generate_series(1, 5) ELSE 0 END FROM tab;
>
> It might seem that this should produce five repetitions of input rows
> that have x > 0, and a single repetition of those that do not; but
> actually it will produce five repetitions of every input row.
>
> So is this too ugly to live, or shall we put up with it?
>
>
Disallowing such an unlikely, and un-intuitive, corner-case strikes my
sensibilities.
I'd rather fail now and allow for the possibility of future implementation
of the "it might seem that..." behavior.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-01-18 23:29:15 | Re: Performance improvement for joins where outer side is unique |
Previous Message | Andres Freund | 2017-01-18 23:19:45 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |