Re: [sqlite] Unsigned

> On Aug 25, 2018, at 5:21 PM, D Burgess wrote: > > The data includes unsigned 32 bit integers which are stored as float > (don't ask me why, I guess the primary reason is the same reason that > 32bit Lua uses floats as integers). That seems like a mistake on their part, since unsigned 32-bit

Re: [sqlite] Unsigned

On 2018/08/26 4:47 PM, Thomas Kurz wrote: But, as noted, you could just store those as blobs, bigendian if you want sorting, and indexing will work just fine. No other conversion needed. Yes, I can store *anything* as blobs. When arguing like this, we wouldn't need strings, dates, floats or

Re: [sqlite] Unsigned

> But, as noted, you could just store those as blobs, bigendian if you want > sorting, and indexing will work just fine. No other conversion needed. Yes, I can store *anything* as blobs. When arguing like this, we wouldn't need strings, dates, floats or any other type neither.

Re: [sqlite] Unsigned

On Sun, Aug 26, 2018, 2:21 AM D Burgess wrote: > 2. Mixed 64/32 bit system that has integers that use the full 64 bits. > Numbers are sourced by realtime hardware. > Absence of 64 bit unsigned means addition of few functions to handle > inserts and display representation(s), numbers stored as

Re: [sqlite] Unsigned

The original question was that I was curious about the history. Noting where we are now at, I will give as examples of two real world applications: 1. 32 bit embedded sqlite. Realtime storing data from various hardware interfaces. The data includes unsigned 32 bit integers which are stored as

Re: [sqlite] Unsigned

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

Re: [sqlite] Unsigned

> 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

Re: [sqlite] Unsigned

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

Re: [sqlite] Unsigned

> On Aug 23, 2018, at 4:22 AM, Wout Mertens 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

Re: [sqlite] Unsigned

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);

Re: [sqlite] Unsigned

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

Re: [sqlite] Unsigned

. - Original Message - From: Simon Slavin To: SQLite mailing list Sent: Wednesday, August 22, 2018, 20:06:38 Subject: [sqlite] Unsigned On 22 Aug 2018, at 6:04pm, Jens Alfke wrote: > Bignums make unsigned types irrelevant, if the only reason you need unsigned > is to store 64-bit po

Re: [sqlite] Unsigned

On 22 Aug 2018, at 6:04pm, Jens Alfke 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

Re: [sqlite] Unsigned

> On Aug 22, 2018, at 10:04 AM, Randall Smith 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

Re: [sqlite] Unsigned

>>> From: D Burgess >>> 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

Re: [sqlite] Unsigned

> On Aug 21, 2018, at 9:54 AM, Randall Smith 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

Re: [sqlite] Unsigned

> Le 22 août 2018 à 00:46, D Burgess 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

Re: [sqlite] Unsigned

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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unsigned

> 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 sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Unsigned

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 wrote: > >>> Date: Tue, 21 Aug 2018 16:46:48 +1000 > >>> From: D Burgess > >>> > >>> Is there a historical

Re: [sqlite] Unsigned

>>> Date: Tue, 21 Aug 2018 16:46:48 +1000 >>> From: D Burgess >>> >>> 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

Re: [sqlite] Unsigned

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 wrote: > My problem is getting

Re: [sqlite] Unsigned

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

Re: [sqlite] Unsigned

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

[sqlite] Unsigned

Is there a historical reason why sqlite does not have a UNSIGNED type to go with INTEGER? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] UNSIGNED BIG INT in SQLite 3.7.11.

...@sqlite.org] Gesendet: Freitag, 06. September 2013 16:04 An: General Discussion of SQLite Database Betreff: Re: [sqlite] UNSIGNED BIG INT in SQLite 3.7.11. On Fri, Sep 6, 2013 at 10:00 AM, Hick Gunter <h...@scigames.at> wrote: > > My guess is that you have exceeded the range of a 32

Re: [sqlite] UNSIGNED BIG INT in SQLite 3.7.11.

On Fri, Sep 6, 2013 at 10:00 AM, Hick Gunter wrote: > > My guess is that you have exceeded the range of a 32 bit integer > (0x7FFF) which will be rendered as a negative number by the SQLite > shell. > The shell works just fine with 64-bit signed integers: SQLite version

Re: [sqlite] UNSIGNED BIG INT in SQLite 3.7.11.

number by the SQLite shell. -Ursprüngliche Nachricht- Von: Filip Curcic [mailto:curcic.fi...@gmail.com] Gesendet: Freitag, 06. September 2013 13:21 An: sqlite-users@sqlite.org Betreff: [sqlite] UNSIGNED BIG INT in SQLite 3.7.11. Hello, I am using Android 4.2 with SQLite 3.7.11 database. I am

[sqlite] UNSIGNED BIG INT in SQLite 3.7.11.

Hello, I am using Android 4.2 with SQLite 3.7.11 database. I am not being able to insert UNSIGNED BIG INT data properly. It looks to me like an overflow, because when I read it out I get a negative number. That only happens on this device, I have another 2.3 Andriod device which runs older

[sqlite] Unsigned int 64 in WHERE

Hi! I have a table with a timestamp column which I use to insert sqlite_uint64 values using sqlite3_bind_int64() (values are retreived using sqlite3_column_int64() with a cast to sqlite_uint64). This works fine with the C API. The problem is that when I try to use the sqlite3 command line, if I

Re: [sqlite] Unsigned 64 bit integers

No. The range is for 64 bit signed. SQLite has manifest typing it is like Ruby Duck Typing or Dynamic Typing. The value defines the type not the column type or lack there of it. If you value is a small integer it will only use 1 byte. On Sat, Jun 28, 2008 at 6:02 PM, freeav8r <[EMAIL PROTECTED]>

[sqlite] Unsigned 64 bit integers

Hi. I have a newbie question. When trying to store 64-bit unsiged integers in sqlite, some of them come back as floats. There is some internal reference on the web page to 64-bit unsiged integers; http://www.sqlite.org/c3ref/int64.html. On the other hand, the faq's entry on AUTOINCREMENT

[sqlite] unsigned integer, text, tutorial, and keys

Hello, I have few questions on SQLite3, i'm using it through pdo with php5. - is unsigned int available? - can we insert a row with an autoinc primary key, so I don't need to provide it when I insert a new row? - if NULL values are possible for primary keys, then autoinc key can't have this

Re: [sqlite] unsigned shorts in bindInt on ARM

I suspect a little vs. big endian problem. chetana bhargav wrote: Hi, I saw a strnage problem using unsigned shorts, not sure if any one saw that, I was using an unsigned short for binding it to integer, the lint wasn't complaining and everything seem to go ahead fine, when I tested that on

[sqlite] unsigned shorts in bindInt on ARM

Hi, I saw a strnage problem using unsigned shorts, not sure if any one saw that, I was using an unsigned short for binding it to integer, the lint wasn't complaining and everything seem to go ahead fine, when I tested that on windows, all my querys were returning as expected. But when I moved