Re: [sqlite] Allow overriding unsigned 64-bit integer

2017-01-08 Thread Kirill Müller
On 08.01.2017 12:54, Clemens Ladisch wrote: Kirill Müller wrote: ... there's no portable support for 64-bit integers. That's what SQLite looks at SQLITE_INT64_TYPE. The patch introduces SQLITE_UINT64_TYPE. I'm working around this issue by using a struct of size 8 A struct of size 8 does

Re: [sqlite] Allow overriding unsigned 64-bit integer

2017-01-08 Thread Kirill Müller
On 08.01.2017 21:24, Richard Hipp wrote: On 1/7/17, Kirill Müller <krlmlr...@mailbox.org> wrote: I'm in a situation [1] where I compile RSQLite as part of a C++ project that still uses the C++98 standard. Can you instead compile SQLite as a library (libsqlite3.a) using gcc or clang, the

Re: [sqlite] Allow overriding unsigned 64-bit integer

2017-01-08 Thread Kirill Müller
On 08.01.2017 17:38, Clemens Ladisch wrote: Kirill Müller wrote: ... there's no portable support for 64-bit integers. I'm working around this issue by using a struct of size 8 I'm open to alternatives. What's wrong with SQLITE_INT64_TYPE? (Even older C++ compilers should have the C .) Thanks

Re: [sqlite] Allow overriding unsigned 64-bit integer

2017-01-08 Thread Kirill Müller
On 08.01.2017 14:20, Clemens Ladisch wrote: Kirill Müller wrote: On 08.01.2017 12:54, Clemens Ladisch wrote: Kirill Müller wrote: ... there's no portable support for 64-bit integers. I'm working around this issue by using a struct of size 8 A struct of size 8 does not behave the same

Re: [sqlite] Allow overriding unsigned 64-bit integer

2017-01-08 Thread Kirill Müller
On 08.01.2017 12:54, Clemens Ladisch wrote: Kirill Müller wrote: ... there's no portable support for 64-bit integers. That's what SQLite looks at SQLITE_INT64_TYPE. The patch introduces SQLITE_UINT64_TYPE. I'm working around this issue by using a struct of size 8 A struct of size 8 does

[sqlite] Allow overriding unsigned 64-bit integer

2017-01-07 Thread Kirill Müller
Hi all I'm in a situation [1] where I compile RSQLite as part of a C++ project that still uses the C++98 standard. This means there's no portable support for 64-bit integers. I'm working around this issue by using a struct of size 8, but this means I need to override the "unsigned 64-bit

Re: [sqlite] ":memory:" path does not seem to work on Windows anymore

2016-06-20 Thread Kirill Müller
On 30.05.2016 17:09, Richard Hipp wrote: On 5/30/16, Kirill Müller <krlmlr...@mailbox.org> wrote: I'd appreciate any pointers on bisecting SQLite. Thanks. (1) Make sure you have tclsh 8.5 or later installed on your system, as there are various TCL scripts that SQLite makefile needs

Re: [sqlite] ":memory:" path does not seem to work on Windows anymore

2016-05-30 Thread Kirill Müller
On 30.05.2016 09:57, Stephan Beal wrote: On Mon, May 30, 2016 at 8:35 AM, Kirill Müller <krlmlr...@mailbox.org> wrote: I can't reproduce the issue on Windows with the current command-line client, but it is real in our environment. How can I help you replicate it? Thanks. -

Re: [sqlite] ":memory:" path does not seem to work on Windows anymore

2016-05-30 Thread Kirill Müller
I can't reproduce the issue on Windows with the current command-line client, but it is real in our environment. How can I help you replicate it? Thanks. -Kirill On 26.05.2016 14:57, Kirill Müller wrote: Hi In the R interface to SQLite [1], we observe that opening a database with ":m

[sqlite] ":memory:" path does not seem to work on Windows anymore

2016-05-26 Thread Kirill Müller
Hi In the R interface to SQLite [1], we observe that opening a database with ":memory:" does not work anymore on Windows (both 32- and 64-bit versions), possibly related to an upgrade from sqlite 3.8.6 to 3.11.1. Using "file::memory:" works on 3.11.1, but not for 3.8.6 . The

[sqlite] Query flattening for left joins involving subqueries on the right-hand side

2015-11-27 Thread Kirill Müller
On 27.11.2015 10:38, Clemens Ladisch wrote: > Kirill M?ller wrote: >> I see no reason why the following two queries can't be executed with the >> same plans: >> >> ... t1 LEFT JOIN t2 ... >> ... t1 LEFT JOIN (SELECT * FROM t2) ... > In this case, the queries are identical. But SQLite's query

[sqlite] Query flattening for left joins involving subqueries on the right-hand side

2015-11-27 Thread Kirill Müller
Exactly. And I'd pretty much like SQLite to figure that out for me ;-) -Kirill On 27.11.2015 03:19, Keith Medcalf wrote: > Would it not be more efficient to say: > > select 1 from t1 limit 1; > > ? > >> -Original Message- >> From: sqlite-users-bounces at mailinglists.sqlite.org

[sqlite] Query flattening for left joins involving subqueries on the right-hand side

2015-11-26 Thread Kirill Müller
On 26.11.2015 21:12, Clemens Ladisch wrote: > Kirill M?ller wrote: >> On 25.11.2015 16:32, Clemens Ladisch wrote: >>> Kirill M?ller wrote: For a left join with a subquery on the right-hand side, that subquery doesn't seem to be flattened. >>> This is rule 3 of

[sqlite] Query flattening for left joins involving subqueries on the right-hand side

2015-11-26 Thread Kirill Müller
On 25.11.2015 16:32, Clemens Ladisch wrote: > Kirill M?ller wrote: >> For a left join with a subquery on the right-hand side, that subquery >> doesn't seem to be flattened. > This is rule 3 of . Thanks, missed that. While true, I wonder if this

[sqlite] Query flattening for left joins involving subqueries on the right-hand side

2015-11-24 Thread Kirill Müller
Hi For a left join with a subquery on the right-hand side, that subquery doesn't seem to be flattened. This seems to work well with an inner join. I have attached a reprex. It creates two tables with $n rows and one ID column each (200k is enough to show substantial slowdown), and joins them