Re: [sqlite] SQLite Android Bindings: how difficult to add LOCALIZED back?
On 9/01/2015 5:00 PM, Dan Kennedy wrote: On 01/08/2015 07:48 AM, Philip Warner wrote: How difficult would it be to add LOCALIZED collation support? I'm guessing that the fact it's not there means it's non-trivial, but I was hoping otherwise... The stumbling block is that the Android implementations use ICU. So to use the Android versions I think we would have to build ICU as a static library as well as SQLite. And ICU is quite large. Thanks for this; I was naively (again) hoping they might have built the unicode stuff as something that was dynamically linkable. I must admit the benefits of a recent build + ability to build custom functions etc is very appealing. btw, do you have an estimate of how big quite large might be? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite Android Bindings: how difficult to add LOCALIZED back?
I just saw the SQLite Android Bindings page at http://www.sqlite.org/android/doc/trunk/www/index.wiki but was a little disappointed to read in the details that UNICODE and LOCALIZED are not supported. I'd really like the latest SQLite, and LOCALIZED. How difficult would it be to add LOCALIZED collation support? I'm guessing that the fact it's not there means it's non-trivial, but I was hoping otherwise... ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Whish List for 2015
Native UNICODE? Dates? UUID (stored as bytes, displayed as string)? I know...new data type representations are unlikely. Triggers with declared variables that are preserved across invocations? (...using temp tables is a pita for storing, say, 5 numbers) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] A question about the ancient history of SQLite triggers
On 6/03/2013 1:59 AM, Jay A. Kreibich wrote: In this case, it is any trigger that invokes any other trigger. Prior to 3.6.18 there was no trigger stack and triggers could be only one layer deep. Ah, thanks. That solves the problem. I can dynamically generate a single inefficient trigger for 3.5.9. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] A question about the ancient history of SQLite triggers
On 5/03/2013 9:53 PM, Richard Hipp wrote: Recursive triggers (triggers that invoke themselves either directly or indirectly) were added in version 3.6.18, 2009-09-11. These are not strictly recursive; the 'when' clause means that trigger 1 will cause trigger 2 to be called etc. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3.exe and formatting binary (GUID) data
John Machin wrote: Assuming your guid is a BLOB, then SELECT other_stuff, QUOTE(guid), etc will display it as hex e.g. X'01020304' This is great; now I can see them at least! P.S. Of course even better would be the ability to read/write GUIDs as properly formatted strings! (Note: I am not asking that they be treated internally as anything other than a binary chunk of data -- just the text form being changed). On output, how do you expect it to determine what blobs are guids? column_name like '%guid%' ?? Yes...is that a problem? I have not really looked at the SQLite code much. I know it remembers the declared types and assigns appropriate internal types. My thinking was that for certain types (GUID, UUID, maybe even Datetime/timestamp etc) it, or the user, could (optionally, for backward compatibility) assign 'toString' and 'fromString' operators. ie. not promote the to full types, but assign them a quasi-type status. In the case of dates, for example, it would allow me to enter '1-Jan-1970' and fromString would produce '1970-01-01'. In the case of GUIDs, it would display and load them in the standard GUID representation. This would not even necessarily need to form part of the standard sqlite code, but could be done as plugable functions. But, as I said, I have not really looked much at sqlite internals to know if this is completely impractical. On input: does the SQL standard define a guid literal? No; but GUIDs do. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3.exe and formatting binary (GUID) data
Hi, I'm using sqlite3 and am very impressed. But, have one small problem. I use binary GUID values and when I 'select' them in the sqlite3 shell, they display as *binary* data, often screwing up the terminal. When I use .dump, or use .mode tcl I get terminal-friendly output. Is there any simple way (or just a hack) that I could persuade the shell to output GUIDs (or all binary data) in the same format as for .dump? Thanks, Philip Warner P.S. Of course even better would be the ability to read/write GUIDs as properly formatted strings! (Note: I am not asking that they be treated internally as anything other than a binary chunk of data -- just the text form being changed). ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
