Unsigned

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unsigned

D Burgess
Is there a historical reason why sqlite does not have a UNSIGNED type
to go with INTEGER?
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Rowan Worth-2
sqlite is pretty loose about types. The column definitions don't constrain
what is stored in the rows at all:

sqlite> CREATE TABLE a(c INTEGER);
sqlite> INSERT INTO a VALUES ("fourty-two");
sqlite> SELECT * FROM a;
fourty-two

So "UNSIGNED" seems kind of pointless as it's implies a further constraint
which is not going to be honoured. Note that sqlite does support actual
constraints via the CHECK clause:

sqlite> CREATE TABLE b(c INTEGER, CHECK (c >= 0));
sqlite> INSERT INTO b VALUES (-15);
Error: constraint failed
sqlite> INSERT INTO b VALUES (15);

Although this is still allowed:

sqlite> INSERT INTO b VALUES ("twenty");
sqlite> SELECT * FROM b;
15
twenty

You can disallow it if you get even more specific:

sqlite> CREATE TABLE b2(c INTEGER, CHECK (TYPEOF(c) == 'integer' AND c >=
0));
sqlite> INSERT INTO b2 VALUES ("twenty");
Error: constraint failed
sqlite> INSERT INTO b2 VALUES (0);
sqlite> INSERT INTO b2 VALUES (-1);
Error: constraint failed
sqlite> INSERT INTO b2 VALUES (1);
sqlite> SELECT * FROM b2;
0
1

Note that the type in the column definition does have an effect - it
defines the column's "affinity" and may change the way data is stored. For
example:

sqlite> INSERT INTO b2 VALUES ("2");
Error: constraint failed

The TYPEOF check rejects this, but without that constraint:

sqlite> INSERT INTO b VALUES ("2");
sqlite> SELECT c, TYPEOF(c) FROM b;
15|integer
twenty|text
2|integer

ie. the text data we tried to insert was converted to an integer for
storage.

Further reading: https://www.sqlite.org/datatype3.html

-Rowan


On 21 August 2018 at 14:46, D Burgess <[hidden email]> wrote:

> Is there a historical reason why sqlite does not have a UNSIGNED type
> to go with INTEGER?
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

D Burgess
My problem is getting handling unsigned integers that have the high
bit set (i.e. negative)
(assume 64bit)
if I insert 0x8000000000000000 (i.e. 9223372036854775808), I would
like to be able to select and get the same unsigned decimal number
back.

select 0x8000000000000000,cast(9223372036854775808 as
integer),printf('%lu %ld 0x%0X 0x%0X',
0x8000000000000000,0x8000000000000000,0x8000000000000000,9223372036854775808);

-9223372036854775808|9223372036854775807|9223372036854775808
-9223372036854775808 0x8000000000000000 0x7FFFFFFFFFFFFFFF

The above select shows the issues.


On Tue, Aug 21, 2018 at 6:25 PM, Rowan Worth <[hidden email]> wrote:

> sqlite is pretty loose about types. The column definitions don't constrain
> what is stored in the rows at all:
>
> sqlite> CREATE TABLE a(c INTEGER);
> sqlite> INSERT INTO a VALUES ("fourty-two");
> sqlite> SELECT * FROM a;
> fourty-two
>
> So "UNSIGNED" seems kind of pointless as it's implies a further constraint
> which is not going to be honoured. Note that sqlite does support actual
> constraints via the CHECK clause:
>
> sqlite> CREATE TABLE b(c INTEGER, CHECK (c >= 0));
> sqlite> INSERT INTO b VALUES (-15);
> Error: constraint failed
> sqlite> INSERT INTO b VALUES (15);
>
> Although this is still allowed:
>
> sqlite> INSERT INTO b VALUES ("twenty");
> sqlite> SELECT * FROM b;
> 15
> twenty
>
> You can disallow it if you get even more specific:
>
> sqlite> CREATE TABLE b2(c INTEGER, CHECK (TYPEOF(c) == 'integer' AND c >=
> 0));
> sqlite> INSERT INTO b2 VALUES ("twenty");
> Error: constraint failed
> sqlite> INSERT INTO b2 VALUES (0);
> sqlite> INSERT INTO b2 VALUES (-1);
> Error: constraint failed
> sqlite> INSERT INTO b2 VALUES (1);
> sqlite> SELECT * FROM b2;
> 0
> 1
>
> Note that the type in the column definition does have an effect - it
> defines the column's "affinity" and may change the way data is stored. For
> example:
>
> sqlite> INSERT INTO b2 VALUES ("2");
> Error: constraint failed
>
> The TYPEOF check rejects this, but without that constraint:
>
> sqlite> INSERT INTO b VALUES ("2");
> sqlite> SELECT c, TYPEOF(c) FROM b;
> 15|integer
> twenty|text
> 2|integer
>
> ie. the text data we tried to insert was converted to an integer for
> storage.
>
> Further reading: https://www.sqlite.org/datatype3.html
>
> -Rowan
>
>
> On 21 August 2018 at 14:46, D Burgess <[hidden email]> wrote:
>
>> Is there a historical reason why sqlite does not have a UNSIGNED type
>> to go with INTEGER?
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Rowan Worth-2
What version is that? I have 3.8.1 handy (ancient I know), which doesn't
support hex literals but:

sqlite> select cast(9223372036854775808 as integer);
-9223372036854775808

Which is different to your result...
-Rowan

On 21 August 2018 at 17:19, D Burgess <[hidden email]> wrote:

> My problem is getting handling unsigned integers that have the high
> bit set (i.e. negative)
> (assume 64bit)
> if I insert 0x8000000000000000 (i.e. 9223372036854775808), I would
> like to be able to select and get the same unsigned decimal number
> back.
>
> select 0x8000000000000000,cast(9223372036854775808 as
> integer),printf('%lu %ld 0x%0X 0x%0X',
> 0x8000000000000000,0x8000000000000000,0x8000000000000000,
> 9223372036854775808);
>
> -9223372036854775808|9223372036854775807|9223372036854775808
> -9223372036854775808 0x8000000000000000 0x7FFFFFFFFFFFFFFF
>
> The above select shows the issues.
>
>
> On Tue, Aug 21, 2018 at 6:25 PM, Rowan Worth <[hidden email]> wrote:
> > sqlite is pretty loose about types. The column definitions don't
> constrain
> > what is stored in the rows at all:
> >
> > sqlite> CREATE TABLE a(c INTEGER);
> > sqlite> INSERT INTO a VALUES ("fourty-two");
> > sqlite> SELECT * FROM a;
> > fourty-two
> >
> > So "UNSIGNED" seems kind of pointless as it's implies a further
> constraint
> > which is not going to be honoured. Note that sqlite does support actual
> > constraints via the CHECK clause:
> >
> > sqlite> CREATE TABLE b(c INTEGER, CHECK (c >= 0));
> > sqlite> INSERT INTO b VALUES (-15);
> > Error: constraint failed
> > sqlite> INSERT INTO b VALUES (15);
> >
> > Although this is still allowed:
> >
> > sqlite> INSERT INTO b VALUES ("twenty");
> > sqlite> SELECT * FROM b;
> > 15
> > twenty
> >
> > You can disallow it if you get even more specific:
> >
> > sqlite> CREATE TABLE b2(c INTEGER, CHECK (TYPEOF(c) == 'integer' AND c >=
> > 0));
> > sqlite> INSERT INTO b2 VALUES ("twenty");
> > Error: constraint failed
> > sqlite> INSERT INTO b2 VALUES (0);
> > sqlite> INSERT INTO b2 VALUES (-1);
> > Error: constraint failed
> > sqlite> INSERT INTO b2 VALUES (1);
> > sqlite> SELECT * FROM b2;
> > 0
> > 1
> >
> > Note that the type in the column definition does have an effect - it
> > defines the column's "affinity" and may change the way data is stored.
> For
> > example:
> >
> > sqlite> INSERT INTO b2 VALUES ("2");
> > Error: constraint failed
> >
> > The TYPEOF check rejects this, but without that constraint:
> >
> > sqlite> INSERT INTO b VALUES ("2");
> > sqlite> SELECT c, TYPEOF(c) FROM b;
> > 15|integer
> > twenty|text
> > 2|integer
> >
> > ie. the text data we tried to insert was converted to an integer for
> > storage.
> >
> > Further reading: https://www.sqlite.org/datatype3.html
> >
> > -Rowan
> >
> >
> > On 21 August 2018 at 14:46, D Burgess <[hidden email]> wrote:
> >
> >> Is there a historical reason why sqlite does not have a UNSIGNED type
> >> to go with INTEGER?
> >> _______________________________________________
> >> sqlite-users mailing list
> >> [hidden email]
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Randall Smith
In reply to this post by D Burgess
>>> Date: Tue, 21 Aug 2018 16:46:48 +1000
>>> From: D Burgess <mailto:[hidden email]>
>>>
>>> Is there a historical reason why sqlite does not have a UNSIGNED type to go with INTEGER?

I would like to enthusiastically second not only this as a feature request, but also request arbitrary-length (or at least much longer length) INTEGER values, as are possible in other SQL dialects.  

There may have been a time in the past when 63 bits was all one could ever conceivably need, but I think we have moved past that time now.  E.g., I have a common need to store software address values, which are (currently!) 64-bit unsigned, and have had to jump through ridiculous hoops in SQLite to do it.  Integers in this range, and larger, seem like they are in common use today.

Randall.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

wmertens
You can just store binary blobs and interpret then in the client, no? Or do
you need to do arithmetic on them?

On Tue, Aug 21, 2018, 6:55 PM Randall Smith <[hidden email]> wrote:

> >>> Date: Tue, 21 Aug 2018 16:46:48 +1000
> >>> From: D Burgess <mailto:[hidden email]>
> >>>
> >>> Is there a historical reason why sqlite does not have a UNSIGNED type
> to go with INTEGER?
>
> I would like to enthusiastically second not only this as a feature
> request, but also request arbitrary-length (or at least much longer length)
> INTEGER values, as are possible in other SQL dialects.
>
> There may have been a time in the past when 63 bits was all one could ever
> conceivably need, but I think we have moved past that time now.  E.g., I
> have a common need to store software address values, which are (currently!)
> 64-bit unsigned, and have had to jump through ridiculous hoops in SQLite to
> do it.  Integers in this range, and larger, seem like they are in common
> use today.
>
> Randall.
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

D Burgess
> You can just store binary blobs and interpret then in the client, no? Or do
you need to do arithmetic on them?

Not arithmetic, but &, |, <<, >>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

D Burgess
I currently store them as blobs. A lot of them, 16 bytes (versus
numeric 8 per item).
And not optimal for indexes.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Olivier Mascia

> Le 22 août 2018 à 00:46, D Burgess <[hidden email]> a écrit :
>
> I currently store them as blobs. A lot of them, 16 bytes (versus
> numeric 8 per item).
> And not optimal for indexes.

Why would you need or use 16 bytes to store  the 8 bytes of a 64 bits integer as a blob?

--
Best regards, Meilleures salutations, Met vriendelijke groeten,  
Olivier Mascia (from mobile device)



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Jens Alfke-2
In reply to this post by Randall Smith


> On Aug 21, 2018, at 9:54 AM, Randall Smith <[hidden email]> wrote:
>
> I would like to enthusiastically second not only this as a feature request, but also request arbitrary-length (or at least much longer length) INTEGER values, as are possible in other SQL dialects.  

Bignums make unsigned types irrelevant, if the only reason you need unsigned is to store 64-bit positive integers. As others have said, "unsigned" is a constraint, not a type.

Bignums would be nice; but you could implement them yourself by storing them as blobs and defining functions to operate on them, which would call into some available C bignum library.

> There may have been a time in the past when 63 bits was all one could ever conceivably need, but I think we have moved past that time now.  E.g., I have a common need to store software address values, which are (currently!) 64-bit unsigned, and have had to jump through ridiculous hoops in SQLite to do it.  Integers in this range, and larger, seem like they are in common use today.

If you're using the C API, you can store and retrieve uint64_t values by casting them to int64_t on the way into the SQLite API and back to uint64_t on the way out. (You should be able to do similar things with other APIs, but it might look uglier.)

Addition, subtraction and bitwise operations should work fine, except for >> because it will shift a 1 into the MSB if the number was >= 2^63.

'<' and '>' will work weirdly because there's a discontinuity at 2^63, so any number ≥ 2^63 will test as less than any number < 2^63. But you can either use SQL logic to work around that, or define a C collation function to compare uint64_t's.

(BTW, I'm curious what these address values are. I thought at first you meant IPv6 addresses, but those are 128-bit, not 64-bit. Or if you mean addresses in the sense of pointers, SQLite now has a C API for representing pointers.)

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Randall Smith
In reply to this post by D Burgess
>>> From: D Burgess <mailto:[hidden email]>

>>> You can just store [large integers as] binary blobs and interpret then in the client, no? Or do

>>> you need to do arithmetic on them?



BLOBs are useful for storage of binary info (e.g., a file), but they are not human readable and require complex conversion when inserting and extracting info from the DB.  AFAIK you can't search or index on them.  They're a poor substitute for an INTEGER.



(FWIW I ended up using a TEXT representation of a large integer, with a custom adapter to convert things back and forth.  This can at least be read by a person when looking at data dumps and so on.  I considered this the least bad of several bad alternatives!  Obviously a native long integer type with normal arithmetic support is the proper solution.)



Randall.






_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Jens Alfke-2


> On Aug 22, 2018, at 10:04 AM, Randall Smith <[hidden email]> wrote:
>
> BLOBs are useful for storage of binary info (e.g., a file), but they are not human readable and require complex conversion when inserting and extracting info from the DB.  

*Shrug* I work with lots of non-human-readable data so I don't see it as a major problem :) And the sqlite blob APIs are pretty simple (just pass a pointer and a size.)

> AFAIK you can't search or index on them.

Yes you can. Blobs support equality tests. If you need to compare them or create an index, you just define a custom collation function (I've done it; it's pretty easy.)

—Jens

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Simon Slavin-3
In reply to this post by Jens Alfke-2
On 22 Aug 2018, at 6:04pm, Jens Alfke <[hidden email]> wrote:

> Bignums make unsigned types irrelevant, if the only reason you need unsigned is to store 64-bit positive integers. As others have said, "unsigned" is a constraint, not a type.

Agreed.

> Bignums would be nice; but you could implement them yourself by storing them as blobs and defining functions to operate on them, which would call into some available C bignum library.

What seems to be needed here is not BIGNUM but would better be called BIGINT.  However, IMHO SQLite should not complicate itself by incorporating a new datatype.  That would lead to a lot of extra CAST() programming and testing.   Instead it should expand the capabilities of the existing INTEGER type.  Looking at section 2.1 of <https://www.sqlite.org/datatype3.html> suggests using a new Serial Type code of, for the sake of argument, 10 to mean "Value is a big-endian 128-bit twos-complement integer.".

This would create schema format 5, and introduce a possible compatibility problem if a database with a big integer was presented to an earlier version of SQLite.  But I think it would represent the minimum of backward compatibility problems.  But I haven't read the source code so I don't know for sure.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Thomas Kurz
+1 for that or a true bignum support (i.e. without any length restriction). The latter would be perfect as it would provide support for storing numbers of encryption keys (RSA, etc.). And it would also avoid the problem of having to extend the bigint range again in a couple of years.



----- Original Message -----
From: Simon Slavin <[hidden email]>
To: SQLite mailing list <[hidden email]>
Sent: Wednesday, August 22, 2018, 20:06:38
Subject: [sqlite] Unsigned

On 22 Aug 2018, at 6:04pm, Jens Alfke <[hidden email]> wrote:

> Bignums make unsigned types irrelevant, if the only reason you need unsigned is to store 64-bit positive integers. As others have said, "unsigned" is a constraint, not a type.

Agreed.

> Bignums would be nice; but you could implement them yourself by storing them as blobs and defining functions to operate on them, which would call into some available C bignum library.

What seems to be needed here is not BIGNUM but would better be called BIGINT.  However, IMHO SQLite should not complicate itself by incorporating a new datatype.  That would lead to a lot of extra CAST() programming and testing.   Instead it should expand the capabilities of the existing INTEGER type.  Looking at section 2.1 of <https://www.sqlite.org/datatype3.html> suggests using a new Serial Type code of, for the sake of argument, 10 to mean "Value is a big-endian 128-bit twos-complement integer.".

This would create schema format 5, and introduce a possible compatibility problem if a database with a big integer was presented to an earlier version of SQLite.  But I think it would represent the minimum of backward compatibility problems.  But I haven't read the source code so I don't know for sure.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

D Burgess
To answer Jens - electronic IDs.

And yes I use bignums on the client side.

Note that I have workarounds and the system I have is stable and
works, I just rue not having 64 bits and UNSIGNED indexes.
There was additional work to get it all going in SQLite. I probably
would not have originally chosen SQLite if I had known what I know
now.

The reason for the original question was that a friend in a different
industry asked me the same question.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

wmertens
I don't understand, can you not just use blobs as primary keys?

$ sqlite3
SQLite version 3.24.0 2018-06-04 19:24:41
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table t(id blob primary key);
sqlite> insert into t values(randomblob(8));
sqlite> insert into t values(randomblob(8));
sqlite> insert into t values(randomblob(8));
sqlite> insert into t values(randomblob(8));
sqlite> select hex(id) from t;
1499C74FAF191054
2DDC29C2D6C72CD8
6BFD11FD9A446A56
99B86AA30E484BCB
sqlite> explain query plan select * from t where id=randomblob(8);
QUERY PLAN
`--SEARCH TABLE t USING COVERING INDEX sqlite_autoindex_t_1 (id=?)
sqlite> select hex(id) from t where id < randomblob(8);
1499C74FAF191054
2DDC29C2D6C72CD8
6BFD11FD9A446A56


On Thu, Aug 23, 2018 at 12:30 AM D Burgess <[hidden email]> wrote:

> To answer Jens - electronic IDs.
>
> And yes I use bignums on the client side.
>
> Note that I have workarounds and the system I have is stable and
> works, I just rue not having 64 bits and UNSIGNED indexes.
> There was additional work to get it all going in SQLite. I probably
> would not have originally chosen SQLite if I had known what I know
> now.
>
> The reason for the original question was that a friend in a different
> industry asked me the same question.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Jens Alfke-2


> On Aug 23, 2018, at 4:22 AM, Wout Mertens <[hidden email]> wrote:
>
> I don't understand, can you not just use blobs as primary keys?

You can. And while the usual bignum encodings won't sort correctly with the default blob collation, you can get around that with clever encoding.

For example, for unsigned bignums you just start with a byte containing the byte-count, followed by the bignum bytes in big-endian order. Signed bignums are a little trickier, but not much (left as an exercise for the reader…)

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Darren Duncan
In reply to this post by D Burgess
On 2018-08-20 11:46 PM, D Burgess wrote:
> Is there a historical reason why sqlite does not have a UNSIGNED type
> to go with INTEGER?

What is the value of a built-in UNSIGNED type when we already have INTEGER?  I
can't think of any. -- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Thomas Kurz
> What is the value of a built-in UNSIGNED type when we already have INTEGER?  I
can't think of any. -- Darren Duncan

Signed integers only allow half the range of values of unsigned ones. You cannot store a pointer value in them. (You can by casting to signed, but then sorting is done wrong.)

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unsigned

Darren Duncan
On 2018-08-24 11:58 PM, Thomas Kurz wrote:
>> What is the value of a built-in UNSIGNED type when we already have INTEGER?  I
> can't think of any. -- Darren Duncan
>
> Signed integers only allow half the range of values of unsigned ones. You cannot store a pointer value in them. (You can by casting to signed, but then sorting is done wrong.)

I fully agree with what others have said, which is that this use case is better
handled by supporting an unlimited precision integer type.  All the "unsigned"
request argues for is a single extra bit of precision for positive integers,
which is like nit-picking; in practice if you can't fit all the integers you
care about in a typical signed machine integer then the unlimited type is the
only reasonable step up, for practical purposes. -- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12