Michael Glaesemann wrote:
>
> On Feb 15, 2008, at 18:11 , Ken Johanson wrote:
>
>> Tom, is it accurate to assume that newer PG versions will further
>> tighten type-strictness (say, '2008-01-01' presently being comparable
>> to a datetime)? Also, do you know of any other vendors that are
>> heading in this direction (removing by default the autocasts)?
>
> '2008-01-01' does not indicate some kind of string: it's just an untyped
> literal. Postgres will determine its type in context.
Exactly, it is performing a context based auto conversion, what some
will call a cast.
select 5<'6' -> true
select 5>'6' -> false
select 15<'60' -> true
select 15>'60' -> false
So one can argue that is is convenient, and safe, to perform the same
implicit/auto conversion for many functions which no longer do that. And
that even if looses-typing / auto cast it allows/encourages bad design,
that does not mean that the all designs cases will be bad. Some users
prefer convenience over type safety, and some of those same users *will*
produce error free code.
On the other hand, should we go the extra mile and failfast when
comparing 5 and '6'? No, because there is clearly only one appropriate
conversion path (cast string to numeric) for the context. Or, some might
argue we should not allow that comparison.
select position('5' in 5)
select position('.' in 5.1)
select position('2008' in current_timestamp)
Numbers and datetime in sql have exactly prescribed standard char
representations (even if others dbs don't use them for datetimes). So
one can argue implicit conversion to char IS safe for these types and
any char-consuming functions.
