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 |
Andres Freund writes:
> On 2017-04-11 17:25:52 -0400, Tom Lane wrote:
>> What was the previous behavior for such cases? If it was reasonably
>> sane, we probably have to preserve it. If it was unpredictable or
>> completely wacko, maybe we don't.
> Previously we'd stash the result in a new tupl
On 2017-04-11 17:25:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Tom, do you have any opinion on the volatility stuff?
>
> What was the previous behavior for such cases? If it was reasonably
> sane, we probably have to preserve it. If it was unpredictable or
> completely wacko, maybe w
Andres Freund writes:
> Tom, do you have any opinion on the volatility stuff?
What was the previous behavior for such cases? If it was reasonably
sane, we probably have to preserve it. If it was unpredictable or
completely wacko, maybe we don't.
regards, tom lane
--
On 2017-01-30 18:54:50 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Wonder if we there's an argument to be made for implementing this
> > roughly similarly to split_pathtarget_at_srf - instead of injecting a
> > ProjectSet node we'd add a FunctionScan node below a Result node.
>
> Yeah, poss
On 2017-03-09 13:34:22 -0500, Robert Haas wrote:
> On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> Wonder if we there's an argument to be made for implementing this
> >> roughly similarly to split_pathtarget_at_srf - instead of injecting a
> >> ProjectSet node we'd
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> >> If you don't want to make ExecInitExpr responsible, then the planner would
> >> have to do something like split_pathtarget_at_srf anyway to decompose the
> >> expressi
Robert Haas writes:
> On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
>> If you don't want to make ExecInitExpr responsible, then the planner would
>> have to do something like split_pathtarget_at_srf anyway to decompose the
>> expressions, no matter which executor representation we use.
> Did
On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> Andres Freund writes:
>> Wonder if we there's an argument to be made for implementing this
>> roughly similarly to split_pathtarget_at_srf - instead of injecting a
>> ProjectSet node we'd add a FunctionScan node below a Result node.
>
> Yeah, pos
Andres Freund writes:
> Wonder if we there's an argument to be made for implementing this
> roughly similarly to split_pathtarget_at_srf - instead of injecting a
> ProjectSet node we'd add a FunctionScan node below a Result node.
Yeah, possibly. That would have the advantage of avoiding an ExecP
On 2017-01-30 17:24:31 -0500, Tom Lane wrote:
> Make it work like Agg and WindowFunc. To wit, dump the actually special
> function calls (the set-returning functions) into a list that's internal
> to the FunctionScan node, and then anything above those goes into scalar
> expressions in the node's
Andres Freund writes:
> On 2017-01-30 16:55:56 -0500, Tom Lane wrote:
>> No, but it allows whatever looks syntactically like a function, including
>> casts. IIRC, we made func_expr work that way ages ago to deflect
>> complaints that it wasn't very clear why some things-that-look-like-
>> functio
Hi,
On 2017-01-30 16:55:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote:
> >> SELECT *
> >> FROM pg_constraint pc,
> >> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
> >> array_upper(pc.conkey, 1)) ELSE NULL END AS int
Andres Freund writes:
> On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote:
>> SELECT *
>> FROM pg_constraint pc,
>> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
>> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
>>
>> Above query is failing with "set-valued f
Hi,
On 2017-01-27 17:58:04 +0530, Rushabh Lathia wrote:
> Consider the below test;
>
> CREATE TABLE tab ( a int primary key);
>
> SELECT *
> FROM pg_constraint pc,
> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position
On Sat, Jan 28, 2017 at 3:43 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia
> wrote:
>
>> Consider the below test;
>>
>> CREATE TABLE tab ( a int primary key);
>>
>> SELECT *
>> FROM pg_constraint pc,
>> CAST(CASE WHEN pc.contype IN (
On Fri, Jan 27, 2017 at 3:13 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> In any case the more idiomatic way of writing your query these days (since
> 9.4 came out) is:
>
> SELECT *
> FROM pg_constraint pc
> LEFT JOIN LATERAL generate_series(1, case when contype in ('f','p','u')
>
On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia
wrote:
> Consider the below test;
>
> CREATE TABLE tab ( a int primary key);
>
> SELECT *
> FROM pg_constraint pc,
> CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
> array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
Consider the below test;
CREATE TABLE tab ( a int primary key);
SELECT *
FROM pg_constraint pc,
CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1,
array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position;
Above query is failing with "set-valued function called in context tha
19 matches
Mail list logo
