Re: [sqlite] Compiling libtclsqlite3.so on Cygwin

On 5/13/2013 16:36, Keith Christian wrote: gcc -o libtclsqlite3.so -shared tea/generic/tclsqlite3.c -lpthread -ldl -ltcl Don't build it that way. It appears that the TEA build system sees Cygwin and thinks "oh, this is Windows, so it must be VC++ or MinGW". That prevents it from linking to

[sqlite] Compiling libtclsqlite3.so on Cygwin

I have the latest version of Cygwin installed (CYGWIN_NT-6.1-WOW64 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin) and the latest autoconf archive (sqlite-autoconf-3071602.tar.gz) because it had the required tclsqlite3.c file in order to build the libtclsqlite3.so shared object. I ran the

Re: [sqlite] SQLite and integer division 1/2=0

On May 12, 2013 11:36 PM, "James K. Lowden" wrote: I'd add also that syntactically the key need is to distinguish "use floating point arithmetic" from "use integer arithmetic" where no other type information is available, specifically in numeric constant literals.

Re: [sqlite] Possible bug in type conversion prior to comparison

On May 13, 2013, at 6:12 PM, Simon Slavin wrote: > I should have asked you for (1,2,20) as well and we could see whether it > outputs '10' or '10.0'. But yes, it would appear that in Oracle, NUMERIC > means FLOAT. Nah. Plus there is no such type as 'NUMERIC' per se in

Re: [sqlite] Foreign Key constraint problem while dropping tables inside transaction

Понедельник, 13 мая 2013, 17:03 +01:00 от Simon Davies : >On 13 May 2013 16:52, Simon Slavin < slav...@bigfraud.org > wrote: >> >> On 13 May 2013, at 3:54pm, Григорий Григоренко < grigore...@mail.ru > wrote: >> >>> sample database is: >>> >>> PRAGMA FOREIGN_KEYS=1;

Re: [sqlite] Possible bug in type conversion prior to comparison

May just be showing best representation main() { float a=1,b=2,c=20; printf("%g\n",a/b*c); } Answer: 10 For c=21 Answer: 10.5 SQL> insert into numtypes values(1,2,20); 1 row created. SQL> select A/B*C from numtypes; A/B*C -- 12.5 13.5 11.5

Re: [sqlite] Possible bug in type conversion prior to comparison

Actually, to be more accurate, the internal storage may be far from a float (as in IEEE double) but a divide on an integer-looking value will certainly be done with floating point math. On Mon, May 13, 2013 at 6:13 PM, Paul van Helden wrote: > > I should have asked you for

Re: [sqlite] Possible bug in type conversion prior to comparison

> I should have asked you for (1,2,20) as well and we could see whether it > outputs '10' or '10.0'. But yes, it would appear that in Oracle, NUMERIC > means FLOAT. > > Of course it does! All the others too. ___ sqlite-users mailing list

Re: [sqlite] Possible bug in type conversion prior to comparison

On 13 May 2013, at 5:08pm, Michael Black wrote: > Would appear it's not doing any casting to promote values but just promoting > everything to float. I should have asked you for (1,2,20) as well and we could see whether it outputs '10' or '10.0'. But yes, it would appear

Re: [sqlite] Possible bug in type conversion prior to comparison

Added that... Would appear it's not doing any casting to promote values but just promoting everything to float. SQL> insert into numtypes values(1,2,21); 1 row created. SQL> select A/B*C from numtypes; A/B*C -- 12.5 13.5 11.5 10.5 -Original Message-

Re: [sqlite] Foreign Key constraint problem while dropping tables inside transaction

On 13 May 2013 16:52, Simon Slavin wrote: > > On 13 May 2013, at 3:54pm, Григорий Григоренко wrote: > >> sample database is: >> >> PRAGMA FOREIGN_KEYS=1; >> CREATE TABLE cat(id INTEGER PRIMARY KEY, name); >> INSERT INTO cat VALUES (1, 'Alice'); >> CREATE

Re: [sqlite] Possible bug in type conversion prior to comparison

On 13 May 2013, at 4:57pm, Michael Black wrote: > Oracle gives the right answer too for example(contrary to what somebody said > earlier). > > create table numtypes (A NUMERIC, B NUMERIC, C NUMERIC); > insert into numtypes values (1, 2, 25.23); > insert into numtypes

Re: [sqlite] Possible bug in type conversion prior to comparison

Seems to me the SQL standard makes no distinction between columns and literals does it? Why should literals be ignored? Oracle gives the right answer too for example(contrary to what somebody said earlier). create table numtypes (A NUMERIC, B NUMERIC, C NUMERIC); insert into numtypes values (1,

Re: [sqlite] Foreign Key constraint problem while dropping tables inside transaction

On 13 May 2013, at 3:54pm, Григорий Григоренко wrote: > sample database is: > > PRAGMA FOREIGN_KEYS=1; > CREATE TABLE cat(id INTEGER PRIMARY KEY, name); > INSERT INTO cat VALUES (1, 'Alice'); > CREATE TABLE owner(pet INTEGER REFERENCES cat(id)); > INSERT INTO owner

[sqlite] Foreign Key constraint problem while dropping tables inside transaction

Hi, sample database is: PRAGMA FOREIGN_KEYS=1; CREATE TABLE cat(id INTEGER PRIMARY KEY, name); INSERT INTO cat VALUES (1, 'Alice'); CREATE TABLE owner(pet INTEGER REFERENCES cat(id)); INSERT INTO owner VALUES(1); This script fails to drop tables with  'foreign key constraint failed':

Re: [sqlite] SQLite and integer division 1/2=0

Tim, Simon & Darren, if you read my whole OP you will see that I've discovered this: use REAL instead. My point is that the behaviour of a NUMERIC column is not intuitive and gives mixed results which wouldn't be a problem if the division operator could be modified. My suggestion cannot be too

Re: [sqlite] SQLite and integer division 1/2=0

On 2013.05.12 11:42 AM, Simon Slavin wrote: I think your problem is just that you have columns declared as NUMERIC. You can have REAL behaviour if you want: just declare your columns as REAL instead: I agree with this. In principle, the behavior of addition should be tied to the data type