Re: BUG #7644: Missing implicit types of Result and failing type-conversion

From: Bernhard Reutner-Fischer <rep(dot)dot(dot)nop(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7644: Missing implicit types of Result and failing type-conversion
Date: 2012-11-12 09:14:03
Message-ID: CAC1BbcQoVod11J6rnR8GMyGBnxTa6irj6hUhcn2yGW=gJZ5BKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 10 November 2012 16:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Bernhard Reutner-Fischer" <rep(dot)dot(dot)nop(at)gmail(dot)com> writes:
> > Fair enough but what about the failure for the case with the Result
> > that fails to merge? There I do have a cast
>
> No you don't:
>
> > select * from (select 'string two' bug ) s2
>
> regards, tom lane
>

I do not need the cast in the second select when using generate_series
either.

select distinct on (bug) bug
from (
select * from (select 'string one'::text bug from generate_series(0,1))
s1
UNION
select * from (select 'string two' bug) s2
-- select * from (select 'string two' bug from generate_series(0,0)) s2
) x
;

IMO this contradicts the "Type Resolution for UNION, CASE, and Related
Constructs" from the documentation.
4) Choose the first non-unknown input type which is a preferred type in
that category, if there is one.

Please explain why the two selects for 'string two' in the example above
behave different?

Many TIA && cheers,

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message stefano 2012-11-12 10:14:49 BUG #7653: Minor problem with join condition
Previous Message Andreas.Heiduk 2012-11-11 18:35:35 BUG #7652: Documentation index lacks functions from "Additional Supplied Modules"