Re: [sqlite] SQL Murder Mystery

> On 16 Dec 2019, at 04:59, Simon Slavin wrote: > > A little light relief: > > > > Chosen SQL variation is SQLite ! Nice, but the crime is so easy to solve … SELECT CAST(x'4A6572656D7920426F77657273' AS TEXT); ;-)

Re: [sqlite] Regarding CoC

> On 23 Oct 2018, at 07:04, Paul wrote: > > If my opinion has any value, even though being atheist, I prefer this CoC 100 > times over > the CoC that is being currently pushed onto the many open-source communities, > that was > created by some purple-headed feminist with political motives.

Re: [sqlite] "Responsive" website revamp at www.sqlite.org

> On 6 Sep 2016, at 10:19, Stephan Beal wrote: > > A counter-opinion, though apparently in the small minority: i _absolutely > despise_ fixed-width web site layouts. +1, including layouts with fixed maximum width. ___

[sqlite] Sqlite incompatibility with Postgres

Consider this set of integers: 1,3,5,7,42,99,83,11,83,83 In this case, there is no subset S1 of size 3 that satisfies your criterion. In an SQL query, the set returned by LIMIT 3 would not be defined uniquely. Best, Stefan Evert

Re: [sqlite] ANN - DBD::SQLite version 1.20

Thanks a lot, Darren! This version also fixes the problems I've been having with segfaults in the create_function test that I've been worried about. I've only tried version 1.22_02, but according to the change log, the bug was fixed before the public release of 1.20. Best, Stefan

Re: [sqlite] speeding up row by row lookup in a large db

>> Just wanted to say publicly that DBD::SQLite is the greatest thing >> since, well, SQLite. Thanks for making our lives easy. > > +1 $count++; from me, too. We talk so much about speed and versions only because we use DBD::SQLite so heavily. BTW, I've switched to the amalgamation package,

Re: [sqlite] speeding up row by row lookup in a large db

On 22 Mar 2009, at 00:27, P Kishor wrote: > Stefan, you were right about "Depends on how much data" part, but it > applied to the weather data, not the lookup tables for lc (or > landcover) or dist (or disturbance). > > Also, "Even for Perl/DBI" makes it seem there is something wrong with >

Re: [sqlite] speeding up row by row lookup in a large db

roach, although my definition of good performance is rather along the lines of "completes within less than 5 seconds". :-) Best regards, Stefan Evert [ stefan.ev...@uos.de | http://purl.org/stefan.evert ] ___ sqlite-users mailing list s

Re: [sqlite] Any advantage to pre-sorting data before loading and indexing it?

data for one of them, so on average there will be little gain. Best regards, Stefan Evert [ stefan.ev...@uos.de | http://purl.org/stefan.evert ] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] request to become co-maintainer of DBD::SQLite

any experience with DBI, which seems to have its own method of compiling C extensions for DBD modules (from a quick look at the DBD::SQLite sources). Just let us know how/whether we can help you! Best regards, Stefan Evert [ stefan.ev...@uos.de | http

Re: [sqlite] Journal files

> I tried that on sqlite3 version 3.6.6 and the return value was "OFF" > but the > journals are still being created. Any reason why this wouldn't work? Did you set PRAGMA journal_mode = OFF; ? The way I read the documentation (on a second or third close reading, I think), this only