Re: [sqlite] Unsigned

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


Re: [sqlite] Unsigned

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


Re: [sqlite] Unsigned

2018-08-21 Thread Wout Mertens
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 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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Possible NULL DEREFERENCES and DEAD STORES found by static analysis tools

2018-08-21 Thread Wout Mertens
I was curious so I  looked it up, the 2015 one is here
http://sqlite.1065341.n5.nabble.com/Security-issues-in-SQLite-td81339.html
but the 2014 one didn't get any replies.

The gist of it is that these static analysis tools generate a lot of false
positives, so unless you can come up with a test case where the condition
is triggered, it's probably not a real issue...

On Tue, Aug 21, 2018, 7:53 PM Niall O'Reilly  wrote:

> On 21 Aug 2018, at 10:14, Patricia Monteiro wrote:
>
> > I have been analyzing the latest version of SQLite (3.24.0) with several
> > static analysis tools (Infer, Clang Static Analyzer, Cppcheck and
> Predator)
> > and after manually reviewing the code I have identified the following
> > errors:
>
> Variants of this question crop up from time to time.
>
> Please look in the mailing-list archives for replies from Richard Hipp
> dated
> 22 January 2014 and 23 March 2015, sent in response to earlier similar
> reports.
>
> Best regards,
>
> Niall O'Reilly
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Possible NULL DEREFERENCES and DEAD STORES found by static analysis tools

2018-08-21 Thread Niall O'Reilly
On 21 Aug 2018, at 10:14, Patricia Monteiro wrote:

> I have been analyzing the latest version of SQLite (3.24.0) with several
> static analysis tools (Infer, Clang Static Analyzer, Cppcheck and Predator)
> and after manually reviewing the code I have identified the following
> errors:

Variants of this question crop up from time to time.

Please look in the mailing-list archives for replies from Richard Hipp dated
22 January 2014 and 23 March 2015, sent in response to earlier similar reports.

Best regards,

Niall O'Reilly




signature.asc
Description: OpenPGP digital signature
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Unsigned

2018-08-21 Thread Randall Smith
>>> 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 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] After upgrade from sqlite3 3.8.7.4 to anything after 3.14.1, I get "Error: destination database is in use"

2018-08-21 Thread Richard Hipp
O it looks to me like the
> 'exclusive' command just needs to be removed ... the threadsafe option that
> sqlite3 was built with looks like it is internally handling the locking.

That would be my guess too.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] After upgrade from sqlite3 3.8.7.4 to anything after 3.14.1, I get "Error: destination database is in use"

2018-08-21 Thread Brian Hutchinson
Is this question better suited for the development list? No response at all.

Thanks,

Brian
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] FTS - IF NOT EXISTS missing from sqlite_master

2018-08-21 Thread Richard Hipp
On 8/19/18, Daniel Santiago  wrote:
> Hi,
>
> It seems that when creating a virtual table the 'IF NOT EXISTS' part is
> missing from the sql column in sqlite_master for the recently created table
> entry.
>
> For example:
> sqlite> CREATE VIRTUAL TABLE IF NOT EXISTS `Mail` USING FTS4(`subject`,
> `body`);
> sqlite> SELECT `sql` FROM `sqlite_master` WHERE `name` = 'Mail';

Using a grave accent to quote a column or table name is a mysql-ism.
It only works in MySQL (and also in SQLite because SQLite tries to be
compatible with everybody). The SQL standard notation is double-quote:

SELECT "sql" FROM "sqlite_master" WHERE "name" = 'Mail';


> CREATE VIRTUAL TABLE `Mail` USING FTS4(`subject`, `body`)
>
> Is this intended behaviour?

Yes, it works as intended.  The IF NOT EXISTS has already been
processed and found to be true before the text is inserted into the
sqlite_master table, so why keep it around?
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Variable value vs Static inside the Sqlite datetime function.

2018-08-21 Thread Richard Hipp
On 8/19/18, Misfer Al-Shamrani  wrote:
> Hi everyone,
>
> I’m looking for the proper presentation (syntax) that will use a dynamic
> value from the table instead of a fixed value as given in the common example
> below:
>
> SELECT date('now','+1 month’);
>
> = 2018-09-18
>
> I want to replace the ( “+1” ….. months) with a dynamic value from my table
> field named “Months_Later” (integer datatype)  to give the date after the
> number of months in that field.


   SELECT date('now',printf('%+d months',tab.Months_Later)) FROM tab;

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] Possible NULL DEREFERENCES and DEAD STORES found by static analysis tools

2018-08-21 Thread Patricia Monteiro
I have been analyzing the latest version of SQLite (3.24.0) with several
static analysis tools (Infer, Clang Static Analyzer, Cppcheck and Predator)
and after manually reviewing the code I have identified the following
errors:

1)
Location: sqlite3.c: 91920
Error: NULL DEREFERENCE
Found by: Clang Static Analyzer
Description: In the vdbeMergeEngineInit function of the sqlite3.c: 91920
file, the * pMerger! = NULL check is not performed before doing the
dereference.

2)
Location: sqlite3.c: 199054
Type: NULL DEREFERENCE
Found by: Clang Static Analyzer
Description: In the function fts5BufferCompare arguments are passed to the
memcmp function without checking if they are! = NULL.

3)
Location: sqlite3.c: 169136
Type: NULL DEREFERENCE
Found by: Clang Static Analyzer
Description: In the fts3LcsIteratorAdvance function, the * pIter! = NULL
check is not performed before doing the dereference.

4)
Location: sqlite3.c: 130155
Type: NULL DEREFERENCE
Found by: Clang Static Analyzer
Description: In the sqlite3UpsertDoUpdate function, a situation similar to
the previous one occurs, ie you need to check if pUpsert! = NULL.

5)
Location: sqlite3.c: 128851 / sqlite3.c: 113375 / sqlite3.c: 113253 /
sqlite3.c: 112108 / sqlite3.c: 112344 / sqlite3.c: 106296 / sqlite3.c:
104629
Type: NULL DEREFERENCE
Found by: Infer
Description: The sqlite3GetVdbe function may return NULL, so you must check
if v! = NULL before using it as an argument.

6)
Location: shell.c: 3329
Type: DEAD STORE
Tool: Infer
Description: The iArg counter is incremented at line 3329, however its
value is no longer used in the completionFilter function.
The error report returned by Infer is:

shell.c:3329: error: DEAD_STORE

  The value written to  (type int) is never used.

  3327. if( pCur->zLine==0 ) return SQLITE_NOMEM;

  3328.   }

  3329. > iArg++;

  3330. }

  3331. if( pCur->zLine!=0 && pCur->zPrefix==0 ){

7)
Location: shell.c: 13799 / shellc.c: 14953 /shell.c:4877 /sqlite3.c:67330
Type: DEAD STORE
Found by: Infer and Clang Static Analyzer
Description: The value written in rc is not used, a new value is written to
the variable without the previously written value being used.
One of the error reports returned by Infer  is:

shell.c:14953: error: DEAD_STORE

  The value written to  (type int) is never used.

  14951. }

  14952.   }

  14953. > rc = sqlite3_finalize(pStmt);

  14954.   appendText(, " ORDER BY 1", 0);

  14955.   rc = sqlite3_prepare_v2(p->db, s.z, -1, , 0);

One of the bug reports returned by Clang Static Analyzerzer is:

shell.c:14953:5: warning: Value stored to 'rc' is never read

rc = sqlite3_finalize(pStmt);

^~~~
8)
Location: sqlite3.c: 120122
Type: DEAD STORE
Found by: Infer and Clang Static Analyzer
Description: The value written to the cSep variable is never used. This
variable is used within a for loop on line 120116, however outside that
loop is not used again after being assigned the value ',' at line 120122.
Infer's results report is:

sqlite3.c:120122: error: DEAD_STORE

  The value written to  (type char) is never used.

  120120. if( i==0 ){

  120121.   sqlite3_str_appendf(, "(\"%s\"", pPragma->zName);

  120122. > cSep = ',';

  120123.   i++;

  120124. }

9)
Location: sqlite3.c: 135444
Type: DEAD STORE
Found by: Infer and Clang Static Analyzer
Description: The value written to the pTerm variable is never used.
Infer's results report is:

sqlite3.c:135444: error: DEAD_STORE

  The value written to  (type WhereTerm*) is never used.

  135442.   testcase( idxNew==0 );

  135443.   exprAnalyze(pSrc, pWC, idxNew);

  135444. > pTerm = >a[idxTerm];

  135445.   markTermAsChild(pWC, idxNew, idxTerm);

  135446. }else{


10)
Location: sqlite3.c: 75150
Type: DEAD STORE
Found by: Infer and Clang Static Analyzer
Description: The variable * v is initialized at line 75150 with the value
pParse-> pVdbe, which is not used and at line 75156 is assigned to * v the
same value.
Code:

SQLITE_PRIVATE void sqlite3VdbeExplain(Parse *pParse, u8 bPush, const char
*zFmt, ...){

  if( pParse->explain==2 ){

char *zMsg;

Vdbe *v = pParse->pVdbe;

va_list ap;

int iThis;

va_start(ap, zFmt);

zMsg = sqlite3VMPrintf(pParse->db, zFmt, ap);

va_end(ap);

v = pParse->pVdbe;

iThis = v->nOp;

sqlite3VdbeAddOp4(v, OP_Explain, iThis, pParse->addrExplain, 0,

  zMsg, P4_DYNAMIC);

if( bPush) pParse->addrExplain = iThis;

  }

}

Infer's results report is:

sqlite3.c:75150: error: DEAD_STORE

  The value written to  (type Vdbe*) is never used.

  75148. if( pParse->explain==2 ){

  75149.   char *zMsg;

  75150. > Vdbe *v = pParse->pVdbe;

  75151.   va_list ap;

  75152.   int iThis;
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org

[sqlite] FTS - IF NOT EXISTS missing from sqlite_master

2018-08-21 Thread Daniel Santiago
Hi,

It seems that when creating a virtual table the 'IF NOT EXISTS' part is
missing from the sql column in sqlite_master for the recently created table
entry.

For example:
sqlite> CREATE VIRTUAL TABLE IF NOT EXISTS `Mail` USING FTS4(`subject`,
`body`);
sqlite> SELECT `sql` FROM `sqlite_master` WHERE `name` = 'Mail';
CREATE VIRTUAL TABLE `Mail` USING FTS4(`subject`, `body`)

Is this intended behaviour?

Thanks,
-Dany
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] Variable value vs Static inside the Sqlite datetime function.

2018-08-21 Thread Misfer Al-Shamrani
Hi everyone,

I’m looking for the proper presentation (syntax) that will use a dynamic value 
from the table instead of a fixed value as given in the common example below:

SELECT date('now','+1 month’);

= 2018-09-18

I want to replace the ( “+1” ….. months) with a dynamic value from my table 
field named “Months_Later” (integer datatype)  to give the date after the 
number of months in that field.

Thank you for your  assistance in this inquiry.

Misfer


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Unsigned

2018-08-21 Thread Rowan Worth
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 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 as
> integer),printf('%lu %ld 0x%0X 0x%0X',
> 0x8000,0x8000,0x8000,
> 9223372036854775808);
>
> -9223372036854775808|9223372036854775807|9223372036854775808
> -9223372036854775808 0x8000 0x7FFF
>
> The above select shows the issues.
>
>
> On Tue, Aug 21, 2018 at 6:25 PM, Rowan Worth  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  wrote:
> >
> >> 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
> >>
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Unsigned

2018-08-21 Thread D Burgess
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 as
integer),printf('%lu %ld 0x%0X 0x%0X',
0x8000,0x8000,0x8000,9223372036854775808);

-9223372036854775808|9223372036854775807|9223372036854775808
-9223372036854775808 0x8000 0x7FFF

The above select shows the issues.


On Tue, Aug 21, 2018 at 6:25 PM, Rowan Worth  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  wrote:
>
>> 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
>>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Unsigned

2018-08-21 Thread Rowan Worth
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  wrote:

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


[sqlite] Unsigned

2018-08-21 Thread D Burgess
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