Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> No, that's not it. I'm wondering why it isn't treated as text.
>> Period. Full stop. Nothing to infer.
>
> Because then we would have to provide implicit casts from text to
> everything else, which would be horribly dangerous.
I would like that even less. I like errors on type conflicts.
>> In my view, it is wrong that any of those work. I would expect to
>> have to code one of these:
>
>> select now() < date '2009-01-01'; -- implicit casts should cover
>> select now() < timestamp with time zone '2009-01-01 00:00:00.0';
>
> The current design is a compromise between usability and strictness
> of semantics. This proposal appears to be all strictness and no
> usability.
I was not proposing anything; I was trying to understand the reasons
for the current behavior so that I could think about what might make
sense to address some of the places where current behavior causes a
result which is different from a non-error result should be obtained
under the standard. I couldn't begin to anticipate what might be
acceptable in these situations without understanding the reason things
are as they are.
I do understand that there will be "convenience" extensions to the
standard -- all products do that. I wasn't sure whether that was the
reason for the behavior or whether there was something else in play.
Thanks for clarifying,
-Kevin
