Tom Lane wrote:
Ken Johanson <pg-user@xxxxxxxxxxxxx> 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?
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
