Re: BUG #4085: No implicit cast after coalesce - Mailing list pgsql-bugs

From Jeff Dwyer
Subject Re: BUG #4085: No implicit cast after coalesce
Date
Msg-id 095B69F3-3E11-4458-95FB-487FE3B62EC8@patientslikeme.com
Whole thread Raw
In response to Re: BUG #4085: No implicit cast after coalesce  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
OK, worksforme. I guess I still find it odd, but I much prefer
explicitness & robustness to small values of 'work'.

Thanks for the prompt response.

-Jeff

On Apr 2, 2008, at 7:15 PM, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
>> Jeff Dwyer wrote:
>>> This seems like a bug to me. Why should an explicit cast be
>>> necessary after
>>> a coalesce?
>
>> Because coalesce(null, '1900-1-2') has no other type information
>> attached, so
>> it would have picked text by default as result type, and that then
>> clashes
>> with the result type of coalesce(null,current_date), which can be
>> derived to
>> be date.  This is a robustness improvement: 8.2 and earlier would
>> silently
>> accept coalesce(null, 'abc') and apply text-semantics comparison.
>
> Yes.  The query "worked" in pre-8.3 only for rather small values of
> "work": if you had been using a non-ISO datestyle the comparisons
> would
> in fact have come out wrong.  Also, it being a textual rather than
> date
> comparison, any index on the date column being compared to wouldn't
> have
> been used.
>
>             regards, tom lane

pgsql-bugs by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: BUG #4087: table creation problem using python
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Re: BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data