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
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 |