Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Date: 2017-04-12 18:45:23
Message-ID: 20170412184523.agr3f7vt2gzpdmvi@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-04-11 17:42:42 -0400, Tom Lane wrote:
> Now, that old behavior matches what you got in the RangeFunction case:
>
> regression96=# select * from int4_tbl, cast(case when f1>0 then generate_series(1,2) else null end as int);
> f1 | int4
> -------------+------
> 0 |
> 123456 | 1
> 123456 | 2
> -123456 |
> 2147483647 | 1
> 2147483647 | 2
> -2147483647 |
> (7 rows)
>
> So it would make sense to me for our new behavior to still match the
> targetlist case.
>
> Not sure if that's exactly the same as what you're saying or not.

The patch now indeed returns

regression[20994][1]=# select * from int4_tbl, cast(case when f1>0 then generate_series(1,2) else null end as int);
WARNING: 01000: replacing
LOCATION: frobble_rtefunc, createplan.c:3102
(as you can see, this ain't quite ready)
┌─────────────┬────────┐
│ f1 │ int4 │
├─────────────┼────────┤
│ 0 │ (null) │
│ 0 │ (null) │
│ 123456 │ 1 │
│ 123456 │ 2 │
│ -123456 │ (null) │
│ -123456 │ (null) │
│ 2147483647 │ 1 │
│ 2147483647 │ 2 │
│ -2147483647 │ (null) │
│ -2147483647 │ (null) │
└─────────────┴────────┘
(10 rows)

The basic approach seems quite workable. It's not super extensible to
allow SRFs deeper inside generic ROWS FROM arguments however - I'm not
sure there's any need to work towards that however, I've not heard
demands so far. Any arguments against that?

One other thing where it'd currently affect behaviour is something like:
SELECT * FROM CAST(generate_series(1,0) * 5 as int);

which, in < v10 would return 1 row, but with my patch returns no rows.
That makes a lot more sense in my opinion, given that a plain FROM
generate_series(1,0) doesn't return any rows in either version.

Right now I'm mopping up corner cases where it'd *expand* the set of
currently valid commands in an inconsistent manner. Namely FROM
int4mul(generate_series(..), 5) works, but FROM
composite_returning(somesrf()) wouldn't without additional work. I plan
to continue to error out in either...

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2017-04-12 19:15:53 Re: Cutting initdb's runtime (Perl question embedded)
Previous Message Robert Haas 2017-04-12 18:41:34 Re: Adding support for Default partition in partitioning