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

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

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

On 08.01.2017 21:24, Richard Hipp wrote: On 1/7/17, Kirill Müller 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, then link the compiled *.a

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

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

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

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

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

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

[sqlite] Allow overriding unsigned 64-bit integer

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 typ

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

On 30.05.2016 17:09, Richard Hipp wrote: On 5/30/16, Kirill Müller 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 to run in order to buil

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

On 30.05.2016 09:57, Stephan Beal wrote: On Mon, May 30, 2016 at 8:35 AM, Kirill Müller 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. -Kirill On 26.05.2016 14:57, Kirill M

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

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 &qu

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

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 sqlite3_open_v2(

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

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 opti

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

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 [mailto:

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

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

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 rul

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

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