Re: BUG #4085: No implicit cast after coalesce

From: Jeff Dwyer <jdwyer(at)patientslikeme(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4085: No implicit cast after coalesce
Date: 2008-04-03 13:15:17
Message-ID: 095B69F3-3E11-4458-95FB-487FE3B62EC8@patientslikeme.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmx(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2008-04-03 13:22:34 Re: [BUGS] BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data
Previous Message ITAGAKI Takahiro 2008-04-03 10:37:21 Re: BUG #4087: table creation problem using python