Ken Johanson <pg-user@kensystem.com> writes:
> Tom Lane wrote:
>> These examples miss the point, because they'd give the same answer
>> whether you think the values are text or integer. ...
> Agreed, so should we disallow 7 > '08'?
Maybe, but the usability ramifications would be enormous --- you'd
also be talking about breaking sale_date > '2008-01-20' and other
cases where "leave off the quotes" is not an available option.
In practice the current handling of one-known-and-one-unknown-input
has not seemed to cause problems for people; it almost always does
what they're expecting it to do. It's the cases where the values are
of *known and incompatible* types that silently casting to make them
match has proven to be dangerous.
>>> 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?
I doubt we'll be doing that. It would not fix the problem anyway,
since now that I think about it, your argument doesn't hold for
numbers either. Consider
regression=# select 2.0 / 3.0;
?column?
------------------------
0.66666666666666666667
(1 row)
regression=# select 10 ^ 14;
?column?
-----------------
100000000000000
(1 row)
regression=# select 10 ^ 15;
?column?
----------
1e+15
(1 row)
regression=# select 1.230e15;
?column?
------------------
1230000000000000
(1 row)
There are a large number of details here that are not prescribed by the
SQL standard (much less actually standardized across systems). They
make little or no difference in the numeric domain, but they sure do as
soon as you start doing textual operations.
regards, tom lane
