On Wed, 16 Mar 2016 01:53:59 -0600
Scott Robison wrote:
> > For example, even the operation "select cast(pow(2,65) as integer)"
> > and
> "select cast(-pow(2,65) as integer)" should return NULL rather than
> MAXINT and MININT respectively.
>
> The $64 bit question ;) is how much existing code
On Tue, 15 Mar 2016 19:33:32 -0600
"Keith Medcalf" wrote:
> > Yes, if the string cannot be represented as an integer, CAST should
> > raise a range error. That spares the application from applying the
> > same test in an ad hoc and inconsistent way.
>
> Since there is no way to "trap" such
Hello,
> The $64 bit question ;) is how much existing code might break if such
> changes were made. One can argue that the existing implementation is
> broken, but a lot of software has been written to use it as it is. What
> happens to them if such an improvement is made?
A nuclear launch? ;)
Hello,
I have prepared two minor corrections for the following 2 problems.
It looks they are working fine:
> ++--++
> |VALUE |col_num |CAST(col_num AS NUMERIC)|
>
On Mar 15, 2016 7:33 PM, "Keith Medcalf" wrote:
>
>
> On Tuesday, 15 March, 2016 07:46, James K Lowden wrote
> > To my way of thinking, SQLite's handling of giant integers per se
> > is an edge case. Because such huge numbers don't normally arise, the
> > non-error path (inputs in bounds) almost
On Tuesday, 15 March, 2016 07:46, James K Lowden wrote:
> > 2. CAST(manydigitstext AS INTEGER) == {SMALLEST_INT64,LARGEST_INT64}
> > --- your opinion as I understood you well;
> Yes, if the string cannot be represented as an integer, CAST should
> raise a range error. That spares the
On Tue, 15 Mar 2016 01:02:17 +0100
"Cezary H. Noweta" wrote:
> 2nd row: why REALs can have trailing spaces, while INTEGERs cannot?
> 3rd row: why REALs can have trailing trash, while INTEGERs cannot?
I think we know now that string->integer conversion is pathologically
broken for inputs that
Hello,
On 2016-03-14 22:23, James K. Lowden wrote:
> [...]
Thank you for expanding my list of inconsistencies and things which can
be done in an other manner, with good reasons why ``other'' could become
``better''.
A rationale for my question was born while trying to fix rather obvious
On Mon, 14 Mar 2016 13:25:09 +0100
Clemens Ladisch wrote:
> > that ``SELECT CAST(col AS INTEGER);'' should return (not so) random
> > result set, and receiving any INTEGER should mean that a source
> > string could have trillion or more possible values?
>
> The documentation does not specify
Hello,
On 2016-03-14 13:25, Clemens Ladisch wrote:
> Cezary H. Noweta wrote:
>> Is your opinion
>
> Why would my opinion matter, as opposed to what SQLite actually does?
Because, SQLite behaves in a bit strange manner, which is opposite to
extreme carefulness of SQLite in other areas. I'm
Cezary H. Noweta wrote:
> On 2016-03-14 12:03, Clemens Ladisch wrote:
>> The documentation is quite clear that INTEGERs have 64 bits. So trying
>> to use integers above 9223372036854775807 is something that is better
>> not to be done.
>
> How could somebody use integers above 9223372036854775807
Hello,
On 2016-03-14 12:03, Clemens Ladisch wrote:
> The documentation is quite clear that INTEGERs have 64 bits. So trying
> to use integers above 9223372036854775807 is something that is better
> not to be done.
How could somebody use integers above 9223372036854775807 if they do not
exist?
On Mon, Mar 14, 2016 at 12:03 PM, Clemens Ladisch
wrote:
> Cezary H. Noweta wrote:
> > Is there some more-or-less official list posted somewhere with things
> which is better not to be done?
>
> The documentation is quite clear that INTEGERs have 64 bits. So trying
> to use integers above
Cezary H. Noweta wrote:
> Is there some more-or-less official list posted somewhere with things which
> is better not to be done?
The documentation is quite clear that INTEGERs have 64 bits. So trying
to use integers above 9223372036854775807 is something that is better
not to be done.
Hello,
On 2016-03-14 11:15, Simon Slavin wrote:
> I would never write code which depended on the answer to that
> question. There are many too many ways for it to fail.
Hmmm... The longest paragraph in ``CAST expressions'' section in the
documentation is about STRING => INTEGER. Nice to know
Hello,
What ``SELECT CAST('1' AS INTEGER);'' should give?
(String of one and 20 zeroes). Actually, preceding ``SELECT'' gives
``7766279631452241920''. Should it be ``9223372036854775807'' (MAXINT64)
or ``100'' (String of one and 18 zeroes --- maximum
length
On 14 Mar 2016, at 10:12am, Cezary H. Noweta wrote:
> What ``SELECT CAST('1' AS INTEGER);'' should give?
> (String of one and 20 zeroes). Actually, preceding ``SELECT'' gives
> ``7766279631452241920''. Should it be ``9223372036854775807'' (MAXINT64) or
>
17 matches
Mail list logo
