Re: [sqlite] Encoding and Collation

2011-09-14 Thread Antonio Maniero
> > Just wanted to add a small warning: the problem with using custom > collations is that if you use them in indexes, then all applications that > use the same database must also have the same collation for everything to > work OK. > > I'm aware of this. Thanks. I will build the like function

Re: [sqlite] Encoding and Collation

2011-09-14 Thread Nuno Lucas
On 09/11/2011 08:27 PM, Antonio Maniero wrote: It's very easy to replace the SQLite functions with user-defined ones, so if someone wants to go the easy way (partial support for just the common western scripts) it's easy. And already done by many, if you search the mailing list. It's exactly

Re: [sqlite] Encoding and Collation

2011-09-14 Thread Antonio Maniero
> > You can try my quick and dirty "pseudo-universal" extension for > less-than-perfect Unicode support. > > Go download the extension at http://dl.dropbox.com/u/** > 26433628/unifuzz.zip . Take > the time to fully read the explanations at top of the

Re: [sqlite] Encoding and Collation

2011-09-14 Thread Antonio Maniero
> > In either case the wrapping and registration with > sqlite_create_collation_v2 > is quite easy. > Yes, it is. I thought that the actual algorithm would be harder but I was wrong. It's surprisingly ease and simple to build a simple algorithm to handle utf8 ASCII and Latin Basic plane with

Re: [sqlite] Encoding and Collation

2011-09-13 Thread Jean-Christophe Deschamps
> It's very easy to replace the SQLite functions with user-defined ones, > so if someone wants to go the easy way (partial support for just the > common western scripts) it's easy. And already done by many, if you > search the mailing list. It's exactly what I'm looking for. It could be my

Re: [sqlite] Encoding and Collation

2011-09-12 Thread Jan Hudec
On Sun, Sep 11, 2011 at 11:55:23 -0300, Antonio Maniero wrote: > I doubt it that it would be ease to storing 8859 without string functions > problems. The proper collation would be simple, of course, but probably I > would need to re-implement all string functions too. Am I wrong? > > I can use

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Antonio Maniero
> > Nothing changed, except now the SQLite 3 API *EXPLICITLY* says the > text functions require either UTF-8 or UTF-16, but nothing stops > someone doing the same as with SQLite2 and store it's text as BLOBs. > > I forgot to reply this. I thought about BLOB as it uses single byte storage but

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Antonio Maniero
> > Do you relly know that there is no 8859 encoding? > The standards go from ISO-8859-1 to ISO-8859-16 and you would need to > have collations for all of them and a way to let the user choose which > one is the right one for them (including regional variations). > For me I just need the 8859-1.

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Antonio Maniero
> > Possibly because SQLite3 supports UTF-8 and UTF-16 rather than ASCII. > Assuming you're using the ICU stuff, of course. > Yes, I know that, but I wish to know the reason. Why the authors choose turn off 8859 rather than keep both like as it was before? Technical reason? > Exactly. Though

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Nuno Lucas
On Sun, Sep 11, 2011 at 15:55, Antonio Maniero wrote: >> >> I see. Well, SQLite2 is ancient: that ship has sailed and it's not coming >> back. >> >> Did SQLite2 actually implement case-insensitive comparison on accented >> Latin characters? I honestly don't know - by the time I

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Igor Tandetnik
Simon Slavin wrote: > Though I'm having trouble pointing to a page for the SQLite3 ICU stuff at the > moment. It would be here: http://www.sqlite.org/cvstrac/fileview?f=sqlite/ext/icu/README.txt but the server seems to be down at the moment. -- Igor Tandetnik

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Simon Slavin
On 11 Sep 2011, at 3:55pm, Antonio Maniero wrote: > Maybe someone else could say about the reason that SQLite dropped 8859 > encoding. Possibly because SQLite3 supports UTF-8 and UTF-16 rather than ASCII. Assuming you're using the ICU stuff, of course. > I can use utf8 but for me SQLite

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Antonio Maniero
> > I see. Well, SQLite2 is ancient: that ship has sailed and it's not coming > back. > > Did SQLite2 actually implement case-insensitive comparison on accented > Latin characters? I honestly don't know - by the time I got involved with > SQLite (in late 2005), SQLite2 was already history, and its

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Igor Tandetnik
Antonio Maniero wrote: >>> Why SQLite dropped the 8859 or single byte support for text? Is there >>> any technical reason? >> >> What do you mean, dropped? What exactly used to worked before and has > stopped working now? What event has occurred between then and now that you >

Re: [sqlite] Encoding and Collation

2011-09-11 Thread Antonio Maniero
> > Why SQLite dropped the 8859 or single byte support for text? Is there > > any technical reason? > > What do you mean, dropped? What exactly used to worked before and has stopped working now? What event has occurred between then and now that you attribute the problem to? Maybe I had

Re: [sqlite] Encoding and Collation

2011-09-10 Thread Igor Tandetnik
Antonio Maniero wrote: > Why SQLite dropped the 8859 or single byte support for text? Is there > any technical reason? What do you mean, dropped? What exactly used to worked before and has stopped working now? What event has occurred between then and now that you attribute

[sqlite] Encoding and Collation

2011-09-10 Thread Antonio Maniero
Hi Sorry by my bad English. Why SQLite dropped the 8859 or single byte support for text? Is there any technical reason? Is there any ready simple solution to use case insensitive collation on SQLite to work with non-English (Latin) characters? I don't need and I don't want a full ICU