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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
