From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: check_srf_call_placement() isn't always setting p_hasTargetSRFs |
Date: | 2017-01-16 19:34:58 |
Message-ID: | 22696.1484595298@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I wonder if there should be a seperate expression type for
>> the INSERT ... VALUES(exactly-one-row); since that behaves quite
>> differently.
> Perhaps. Or maybe we should just use EXPR_KIND_SELECT_TARGET for that?
After looking around, I think we probably better use a different
EXPR_KIND; even if all the functionality is identical, we don't want
ParseExprKindName() to say "SELECT" when we're throwing an error for
INSERT...VALUES.
Also, I noticed that we don't actually allow SRFs in VALUES RTEs:
regression=# select * from (values(1,generate_series(11,13)),(2,0)) v;
ERROR: set-valued function called in context that cannot accept a set
That's because ValuesNext doesn't handle it. I'm not particularly
excited about fixing that, given that it's always been that way and
no one has complained yet. But check_srf_call_placement() is misinformed,
since it thinks the case works.
Will go fix these things.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-01-16 20:52:14 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Previous Message | Alvaro Herrera | 2017-01-16 19:30:02 | Re: patch: function xmltable |