Re: Strict-typing benefits/costs

Tom Lane wrote:
> Ken Johanson <pg-user(at)kensystem(dot)com> writes:
>> select 5<'6' -> true
>> select 5>'6' -> false
>> select 15<'60' -> true
>> select 15>'60' -> false
>
> These examples miss the point, because they'd give the same answer
> whether you think the values are text or integer. Consider instead
> these cases:
>
> regression=# select 7 > '60'; -- int > int
> ?column?
> ----------
> f
> (1 row)
>
> regression=# select '7' > '60'; -- text > text
> ?column?
> ----------
> t
> (1 row)
>
> regression=# select 7 > '08'; -- int > int
> ?column?
> ----------
> f
> (1 row)
>
> regression=# select '7' > '08'; -- text > text
> ?column?
> ----------
> t
> (1 row)
>
> All of a sudden it seems much more important to be clear about
> what data type is involved, no?

Agreed, so should we disallow 7 > '08'? Because that is (tell me if you
disagree), much more hazardous than allowing, say TRIM(7) or
POSITION('7' IN 7). Or for non-failfast comparison of two columns of
dissimilar types (say bigint, integer, real, char).

select 'ba'>'ab' -> true
select 'ab'>'ba' -> false
select '0.5'=.5 -> true (is char comparator or numeric to laymen?)
select '7a'<'070' -> true (is char comparator or numeric to laymen?)
select '7a'<70 -> failfast, good.

>
>> Numbers and datetime in sql have exactly prescribed standard char
>> representations (even if others dbs don't use them for datetimes).
>
> See the datestyle parameter before you maintain that Postgres
> should assume that.
>
>

I agree. Unless the date style is know to always be iso8601, which is
not true owed to datestyle. Unless sql spec allows for it, could this be
an argument for removing the datestyle implict (non-iso8601) feature?