On 07/13/2017 08:49 PM, Richard Hipp wrote:
The 3.20.0 release of SQLite is expected in about a week. Please
report any issues that you have with the beta as soon as possible.
Code is available in the "prerelease snapshot" at
https://sqlite.org/download.html
An overview of changes is at
Not really. (At least not for anyone else's Link Time Optimizer)
LTO outputs the intermediate parse tree rather than object code into the
.obj/.a files. The LTO linker merges all the parse tree's into a single parse
tree then generates actual object code. In other words, it makes it "look"
Nicely put. There’s a couple of prepared statements that I’m using that
absolutely will benefit from this, now I understand it.
On 7/13/17, 3:30 PM, "sqlite-users on behalf of Marc L. Allen"
wrote:
If
On 7/13/17, Simon Slavin wrote:
>
> Can I conclude that if "SELECT sql FROM STMT" returns no rows then closing
> the connection should work properly and immediately ?
>
You'll probably always get one row of result, which is the query itself.
Yes, if you only get that one
On 13 Jul 2017, at 7:49pm, Richard Hipp wrote:
> An overview of changes is at https://sqlite.org/draft/releaselog/3_20_0.html
Could I suggest that the STMT virtual table be renamed as something like
sqlite_statements ? Or anything else that starts with "sqlite_" ? I’m
If it's going to change in future releases, then perhaps your "key point" is
the main takeaway that should be documented?
Something like:
SQLITE_PREPARE_PERSISTENT is a hint to SQLite that the prepared statement is
going to linger for a long time and that SQLite should take that into account
On 7/13/17, Dominique Pellé wrote:
>
> Looking at the description of the new SQLITE_PREPARE_PERSISTENT
> at https://sqlite.org/draft/c3ref/c_prepare_persistent.html
> it's not clear to me what are the benefits.
> Shouldn't the description say why it can be beneficial to
Richard Hipp wrote:
> The 3.20.0 release of SQLite is expected in about a week. Please
> report any issues that you have with the beta as soon as possible.
>
> Code is available in the "prerelease snapshot" at
> https://sqlite.org/download.html
>
> An overview of changes is at
On 7/13/17, jungle Boogie wrote:
>
> On doesn't have to be capitalized:
> SQLite Release 3.20.0 On 2017-07-20
>
That is the same capitalization used for all prior releases (ex:
https://www.sqlite.org/releaselog/3_19_3.html and
On 13 July 2017 at 11:49, Richard Hipp wrote:
> The 3.20.0 release of SQLite is expected in about a week. Please
> report any issues that you have with the beta as soon as possible.
>
> Code is available in the "prerelease snapshot" at
> https://sqlite.org/download.html
>
> An
On 13 July 2017 at 11:49, Richard Hipp wrote:
> The 3.20.0 release of SQLite is expected in about a week. Please
> report any issues that you have with the beta as soon as possible.
>
> Code is available in the "prerelease snapshot" at
> https://sqlite.org/download.html
>
> An
On 7/13/17, David Raymond wrote:
> Is there a page for the LSM1 extension?
>
We were just discussing that internally. The current decision is to
omit the LSM1 bullet from the change log for this release. We need to
spend more time on that extension before it is
Is there a page for the LSM1 extension?
Minor typos:
https://sqlite.org/draft/releaselog/3_20_0.html
"Evaluation WHERE clause constraints" -> "Evaluate WHERE clause constraints"
https://sqlite.org/draft/stmt.html
"The enable the STMT extension" -> "To enable the STMT extension"
"in default
The 3.20.0 release of SQLite is expected in about a week. Please
report any issues that you have with the beta as soon as possible.
Code is available in the "prerelease snapshot" at
https://sqlite.org/download.html
An overview of changes is at https://sqlite.org/draft/releaselog/3_20_0.html
On 7/13/17, Jens Alfke wrote:
>
> Have you tested Clang? These days it may generate even better code,
We do a lot of testing with clang - it is part of our standard test
protocol. It generates code that is slightly larger and slower than
the GCC-generated code, but not
> On Jul 13, 2017, at 7:49 AM, Richard Hipp wrote:
>
> I've spent some time investigating this, and I think the answer is
> that GCC simply generates better code.
Have you tested Clang? These days it may generate even better code, especially
with -Ofast and the link-time
On 7/9/17, Bob Friesenhahn wrote:
> On Sat, 8 Jul 2017, Richard Hipp wrote:
>>
>> gcc-5.4: 491585 bytes, 1,124 million CPU cycles.
>> icc-17.0: 536596 bytes, 1,274 million CPU cycles
>
> Sqlite3 has been cycle-optimized for GCC. You now have 29-days to
> also
Hi Simon,
Thank you for your suggestion. Will check it out.
Regards,
Mohan
--
View this message in context:
http://sqlite.1065341.n5.nabble.com/Query-on-bug-fix-for-ticket-7ffd1ca1d2ad4ec-tp96175p96608.html
Sent from the SQLite mailing list archive at Nabble.com.
18 matches
Mail list logo