Re: [sqlite] IEE754-2008 decimal32, decimal64 datatypes and SQLite

On 21 Dec 2009, at 6:59am, Roger Binns wrote: > Simon Slavin wrote: >> I assume one would use an existing Open C library for doing math on >> that new type of data, > > That would be considerably slower than builtin CPU instructions. You > also have the issue of type conversions - eg adding one

Re: [sqlite] IEE754-2008 decimal32, decimal64 datatypes and SQLite

Simon Slavin wrote: > One would probably do it not by changing any existing datatype but by > introducing one or more new ones The existing double could be repurposed. This would all depend on compatibility and other stuff - ie DRH and Jacob would be far better arbiters between them of the best

Re: [sqlite] IEE754-2008 decimal32, decimal64 datatypes and SQLite

On 21 Dec 2009, at 1:09am, Roger Binns wrote: > Not only do you need the type but every arithmetic operation would also need > to be updated. It will be even more fun if you also want to support the > - -1985 representations (eg normal SQLite database format) since you'll have > both semantics i

Re: [sqlite] IEE754-2008 decimal32, decimal64 datatypes and SQLite

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacob Lister wrote: > What provision is there for the inclusion of new data types in SQLite > and is such an inclusion possible or likely in future? Updating or adding a data type would affect the file format and many of the API families (eg sqlite3_

Re: [sqlite] ICU collation

it is written here http://userguide.icu-project.org/collation "A letter can be treated as if it were two letters. For example, in traditional German "ä" is compared as if it were "ae"." On Mon, Dec 21, 2009 at 12:04 AM, Sylvain Pointeau < sylvain.po

Re: [sqlite] ICU collation

I am pretty sure that ICU should handle those cases. Please note that I tried "=" and "like" for that without any luck. On Sun, Dec 20, 2009 at 7:37 PM, Wolfgang Enzinger wrote: > Am Sun, 20 Dec 2009 19:24:58 +0100 schrieb Wolfgang Enzinger: > > > I'm pretty sure they don't query their database f

[sqlite] IEE754-2008 decimal32, decimal64 datatypes and SQLite

Hello all, Our organization is moving towards storing data values in the newly defined IEEE754-2008 decimal floating point point standard: http://en.wikipedia.org/wiki/IEEE_754-2008 What provision is there for the inclusion of new data types in SQLite and is such an inclusion possible or lik

Re: [sqlite] ICU collation

Am Sun, 20 Dec 2009 19:24:58 +0100 schrieb Wolfgang Enzinger: > I'm pretty sure they don't query their database for " = 'schön'" but for > "LIKE 'schön'". Correction: I'm pretty sure they don't query their database for " = 'schoen'" but for "LIKE 'schoen'". ___

Re: [sqlite] ICU collation

Am Sun, 20 Dec 2009 14:45:15 +0100 schrieb Sylvain Pointeau: > if you go on http://www.dict.cc and type "schoen" then it will give you >the answers "schön" ... I'm pretty sure they don't query their database for " = 'schön'" but for "LIKE 'schön'". And that's exactly what it is: like, but not eq

Re: [sqlite] ICU collation

You can see how some people handle this situation here, Sylvain: http://php.net/manual/de/normalizer.normalize.php If you want umlauted 'a' (ä) to be treated the same as the two characters 'ae' (such treatment is an older convention from the days of typewriters later adopted for ASCII) the appl

Re: [sqlite] ICU collation

Hi, I think in 99% of all cases ö, ü, ä is equal to oe, ue, ae but I have no idea about ICU. Actually ö evolved from oe (I just learned that from wikipedia .-) ). But there are some words like 'tu' (doing) with a form like e.g. 'Ich tue ...' (I am doing ...') where 'tue' is of course not equ

Re: [sqlite] ICU collation

Hi, if you go on http://www.dict.cc and type "schoen" then it will give you the answers "schön" ... I thought that using ICU, I could interrogate my database in the same way. (I am doing this kind of application for students only) I am actually learning german and my teacher

Re: [sqlite] FTS3 performance rowid vs docid

On Dec 18, 2009, at 10:53 PM, Eric Grange wrote: > Hello All, > > Using 3.6.21 and FTS3, I've noticed than when doing search queries, > using docid as in > > select fts.docid from fts where fts.content match "la" > > the search is much slower than when using rowid as in > > select fts.rowid fro

[sqlite] Patch for sqlite3_*_auxdata interface

Hello! The simple regexp function example: select value from t1 where user_regexp_multi(value,'\d{1}','\s+')=1; The function user_regexp_multi(value,regexp1,...,regexpN) will recompile the regexp by every call becouse auxdata API cleaning the function-context auxdata too often. And thus we use a