> Also note that if you store your numbers as strings, indexes on those
> values will order them as strings. In other words, searching and sorting
> will work incorrectly.
> It should be possible to get your numbers from a Java numeric variable to
> a database numeric value without passing them t
As quick insight I gleaned from this list sometime ago: if you only need to
be able to search and sort, the blobs can be used.
If you can live with a fixed size (f.i. 256bits), then just use the
fixed-size big-endian representation as blob content.
For variable-length big integers, encode them as
On 2 May 2018, at 6:08pm, Thomas Kurz
wrote:
> Are there any plans for supporting a true BigInt/HugeInt data type (i.e.
> without any length restriction) in the near future?
The largest integer storable as an integer is current 2^63-1, which is the
value as signed BigInt in many libraries. I
Are there any plans for supporting a true BigInt/HugeInt data type (i.e.
without any length restriction) in the near future?
- Original Message -
From: Simon Slavin
To: SQLite mailing list
Sent: Wednesday, May 2, 2018, 19:04:33
Subject: [sqlite] How to Handle BigInt
On 2 May 2018
On 2 May 2018, at 5:22pm, dmp wrote:
> Since I'm using Java and JDBC I was retrieving numeric fields in PostgreSQL
> with getString(), handles all, then using Integer.parseInt(stringValue) for
> BigInts in storing to SQLite.
>
> There lies the problem since BigInt values were exceeding the rang
> SQLite integers are all 64 bit - I don't about postgress, so unless
> postgress allows integers bigger than 64 bit, and you use them, you should
> be OK with your table definitions above.
> Paul
Hello,
That really provides insight to the real issue, I was having and so therefore
the question.
Perhaps, but that is only part of the story, and all of that is hidden from
the user and is only relevant in terms of how the number is stored on disk.
You can define a column as int, smallint, largeint, bigint, etc and,
irrespective of which you use, SQLite will save the data to disk
transparently
From the docs:
*INTEGER*. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8
bytes depending on the magnitude of the value.
So perhaps you should have said " SQLite integers are all up to 64 bit."
Gerry
On Tue, May 1, 2018 at 8:56 AM, Paul Sanderson wrote:
> SQLite integers are all
SQLite integers are all 64 bit - I don't about postgress, so unless
postgress allows integers bigger than 64 bit, and you use them, you should
be OK with your table definitions above.
Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sanderson
Hello,
Given a conversion from a database table that contains BigInt, long,
field from PostgreSQL to a SQLite similar table.
CREATE TABLE postgresqltypes (
data_type_id serial,
bigInt_type bigint)
CREATE TABLE sqlitetypes (
data_type_id INTEGER PRIMARY KEY AUTOINCREMENT,
int_type INTEGER
10 matches
Mail list logo