Re: [sqlite] Version 3.20.0 coming soon...

[Yuriy M. Kaminskiy]

On 07/18/17 16:37 , Stephan Buchert wrote:
> The command history (Ctrl-R) of the shell is still intact with the new tab
> completion, but I had experienced it often as way too short (too few
> lines). So I have searched now in the source code, the line in shell.c is
>
>   if( zHistory ){
> shell_stifle_history(100);
> ...
>
> in case somebody wants to increase it to more than 100.
>
> An obvious suggestion (already for 3.20.0?) is to make the history depth
> configurable, perhaps when compiling the shell.

I posted patch about six years ago.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Version 3.20.0 coming soon...

[Stephan Buchert]

The command history (Ctrl-R) of the shell is still intact with the new tab
completion, but I had experienced it often as way too short (too few
lines). So I have searched now in the source code, the line in shell.c is

  if( zHistory ){
shell_stifle_history(100);
...

in case somebody wants to increase it to more than 100.

An obvious suggestion (already for 3.20.0?) is to make the history depth
configurable, perhaps when compiling the shell.

/Stephan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Version 3.20.0 coming soon...

[Stephan Buchert]

The tab completion in the sqlite3 shell works, which is nice, but it seems
to shadow readline's normal file name completion when hitting tab at for
example

sqlite> .read "sq

which is not so nice... (i.e. no file name completion any more for .read ,
.attach and the like...)

/Stephan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

On 7/17/17, petern  wrote:
> Missing documentation or wrong extension source?

The documentation and code you are looking are from different branches.

>
> https://www.sqlite.org/src/file/ext/misc/remember.c line 51:
> -> ptr = sqlite3_value_pointer(argv[1], "carray");
>
> This signature, 'void* sqlite3_value_pointer(V,T)' , is not documented here:
>
> https://sqlite.org/draft/c3ref/value_blob.html
>
> Nor is there any mention about the additional parameter T when setting the
> result here:
>
> https://sqlite.org/draft/c3ref/result_blob.html
>
> Nor here:
>
> https://sqlite.org/draft/c3ref/bind_blob.html
>
> I suppose that's consistent but it would be nice to read about the new API.
>
> The only clue about how it works is a brief statement in change header of
> remember.c:
>
> "The pointer type is a string that must compare equal using strcmp() or
> else the pointer comes through as a NULL."
>
> On Thu, Jul 13, 2017 at 11:49 AM, 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 https://sqlite.org/draft/
>> releaselog/3_20_0.html
>>
>> You can send issues to this email list, or directly to me.
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[petern]

Missing documentation or wrong extension source?

https://www.sqlite.org/src/file/ext/misc/remember.c line 51:
-> ptr = sqlite3_value_pointer(argv[1], "carray");

This signature, 'void* sqlite3_value_pointer(V,T)' , is not documented here:

https://sqlite.org/draft/c3ref/value_blob.html

Nor is there any mention about the additional parameter T when setting the
result here:

https://sqlite.org/draft/c3ref/result_blob.html

Nor here:

https://sqlite.org/draft/c3ref/bind_blob.html

I suppose that's consistent but it would be nice to read about the new API.

The only clue about how it works is a brief statement in change header of
remember.c:

"The pointer type is a string that must compare equal using strcmp() or
else the pointer comes through as a NULL."

On Thu, Jul 13, 2017 at 11:49 AM, 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 https://sqlite.org/draft/
> releaselog/3_20_0.html
>
> You can send issues to this email list, or directly to me.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon... _rl_completion_matches undefined on old iMac

[E.Pasma]

Richard Hipp wrote:


E.Pasma wrote:

Is there any otrher choice except  ./configure --disable-readline.


Other options:

(1) You can upgrade the readline library on your PPC to something more
recent that supports tab completion.

(2) You can compile the shell using linenoise instead of readline.
(Doing so will require manual changes to the Makefile as it does not
appear to be supported by ./configure at this time - something that we
should fix for the next release.)

I still power up a PPC mac from time to time in order to verify that
SQLite works on big-endian platforms.  But it is painfully slow.  Why
are you still using a PPC mac?


Thanks for pointing this out and I managed to use linenoise from 
https://github.com/antirez/linenoise
I was pleased to find that the use of the linenoise library is already  
anticipated in shell.c (HAVE_LINENOISE)

Indeed only Makefile need to be changed manually aftter .configure.
The difference in size of the library source code is impressing:

$ du -hs readline-7.0/
 11Mreadline-7.0/
$ du -hs linenoise/
144Klinenoise/

Point about new PC taken. Even download from github seems not to work  
on a PPC mac.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon... _rl_completion_matches undefined on old iMac

[Richard Hipp]

On 7/15/17, E.Pasma  wrote:
> Hello, when building the pre-release snapshot an error occurs. It is
> likely due to my outdated Mac OS version, 10.5.8.
>
> shell.c: In function ‘readline_completion’:
> shell.c:4286: warning: return makes pointer from integer without a cast
> ...
> Undefined symbols:
>"_rl_completion_matches", referenced from:
>_readline_completion in sqlite3-shell.o
>
> I can not upgrade Mac OS X on a PPC any further.
> Is there any otrher choice except  ./configure --disable-readline.

Other options:

(1) You can upgrade the readline library on your PPC to something more
recent that supports tab completion.

(2) You can compile the shell using linenoise instead of readline.
(Doing so will require manual changes to the Makefile as it does not
appear to be supported by ./configure at this time - something that we
should fix for the next release.)

I still power up a PPC mac from time to time in order to verify that
SQLite works on big-endian platforms.  But it is painfully slow.  Why
are you still using a PPC mac?

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon... _rl_completion_matches undefined on old iMac

[E.Pasma]

Hello, when building the pre-release snapshot an error occurs. It is  
likely due to my outdated Mac OS version, 10.5.8.


shell.c: In function ‘readline_completion’:
shell.c:4286: warning: return makes pointer from integer without a cast
...
Undefined symbols:
  "_rl_completion_matches", referenced from:
  _readline_completion in sqlite3-shell.o

I can not upgrade Mac OS X on a PPC any further.
Is there any otrher choice except  ./configure --disable-readline.
Thanks, E. Pasma



Op 13 jul 2017, om 20:49 heeft Richard Hipp het volgende geschreven:


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

You can send issues to this email list, or directly to me.

--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[petern]

Regarding the new pointer value/result pseudo-null API:

void *sqlite3_value_pointer(sqlite3_value*);
void sqlite3_result_pointer(sqlite3_context*, void*);

Assuming sqlite3_value_type() returns SQLITE_NULL for these pseudo-nulls,
and thinking ahead, an additional pointer type API pair would be natural
here:

int sqlite3_result_pointer_type(sqlite3_context*, void*); could receive a
matching user defined pointer_type from a second form
sqlite3_result_pointer call:

void sqlite3_result_pointer(sqlite3_context*, void*,int pointer_type);

One feature of passing pointers as SQLITE_BLOB is that byte size can be
inspected to somewhat validate pointer type. For wider applicability of the
new value_pointer's, adding pointer_type information to the API would be
very helpful.  For one, I could upgrade many value_blob pointers to
value_pointer right away.

Here is a proposal about how int sqlite3_value_pointer_type(sqlite3_value*)
could work:

Regular NULL would return -1 or other suitable sentinel while value_pointer
NULL set by the first form sqlite3_result_pointer(C,P) would return
value_pointer_type 0.  Then, value_pointer NULL set by the second form
sqlite3_result_pointer(C,P,T) would return value_pointer_type according to
the third parameter, int pointer_type T.

In addition to conveying a user defined type, this arrangement would also
support unambiguous conveyance of a null value_pointer.

A fuller implementation of value_pointer pseudo-nulls along these lines
would be most welcome and  immediately applied to testing cycles of my
projects under 3.20.0.

Peter


On Thu, Jul 13, 2017 at 11:49 AM, 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 https://sqlite.org/draft/
> releaselog/3_20_0.html
>
> You can send issues to this email list, or directly to me.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

The STMT extension has been renamed as SQLITE_STMT.

Updated code is in the prerelease snapshot on
https://sqlite.org/download.html and the draft documentation
(https://sqlite.org/draft/index.html) has been updated.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Sylvain Pointeau]

I wonder how SQLITE_PREPARE_PERSISTENT can be used in a jdbc driver. Do you
have any idea?
(seems like there is no possibility to know about it from the jdbc API)

is it better to always set this flag or to never do it?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Don V Nielsen]

> perhaps the devs can invent some other namespace

Seconded. I would like to think the devs, themselves, would like to create
some sort of namespace or isolation for the structures created by the
extensions. A little more gusto in the name, rather than STMT, would always
be appreciated. imo

On Fri, Jul 14, 2017 at 5:31 AM, Simon Slavin  wrote:

>
>
> On 14 Jul 2017, at 8:50am, Clemens Ladisch  wrote:
>
> > There already is an "sqlite_" namespace, and it is reserved for internal
> > objects of SQLite itself.
> >
> > The STMT virtual table is an extension that must be explicitly enabled.
> > (The sqlite3 command-line shell does so by default, but it already did
> > with other extensions like fileio, and it does not actually have the
> > same API stability guarantees as the SQLite library.)
>
> Then perhaps the devs can invent some other namespace for this new
> category of thing.  I don’t mind what the name is, I would just like the
> entity to be clearly marked as not one of mine.  The ability to filter out
> names including underline characters is very useful.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Simon Slavin]

On 14 Jul 2017, at 8:50am, Clemens Ladisch  wrote:

> There already is an "sqlite_" namespace, and it is reserved for internal
> objects of SQLite itself.
> 
> The STMT virtual table is an extension that must be explicitly enabled.
> (The sqlite3 command-line shell does so by default, but it already did
> with other extensions like fileio, and it does not actually have the
> same API stability guarantees as the SQLite library.)

Then perhaps the devs can invent some other namespace for this new category of 
thing.  I don’t mind what the name is, I would just like the entity to be 
clearly marked as not one of mine.  The ability to filter out names including 
underline characters is very useful.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Clemens Ladisch]

Eric Grange wrote:
>> Could I suggest that the STMT virtual table be renamed as something like 
>> sqlite_statements ?
>> Or anything else that starts with "sqlite_" ?
>
> Seconded, especially as more and more virtual tables become available (a
> good thing), there is a greater risk of name collision, so an "sqlite_"
> namespace would be nice.

There already is an "sqlite_" namespace, and it is reserved for internal
objects of SQLite itself.

The STMT virtual table is an extension that must be explicitly enabled.
(The sqlite3 command-line shell does so by default, but it already did
with other extensions like fileio, and it does not actually have the
same API stability guarantees as the SQLite library.)


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Eric Grange]

> Could I suggest that the STMT virtual table be renamed as something like
sqlite_statements ?
> Or anything else that starts with "sqlite_" ?

Seconded, especially as more and more virtual tables become available (a
good thing), there is a greater risk of name collision, so an "sqlite_"
namespace would be nice.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Basile Starynkevitch]

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 https://sqlite.org/draft/releaselog/3_20_0.html

You can send issues to this email list, or directly to me.



https://sqlite.org/draft/releaselog/3_20_0.html  says:

 * Added the "--newlines" option to the ".dump
   " command to cause U+000a
   and U+000d characters to be output literally rather than escaped
   using the replace()
    function.

This change is welcome, but quite strange. See my message (wishing it)
 
http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2017-July/073642.html
and 
https://stackoverflow.com/questions/44989176/sqlite3-dump-inserts-replace-function-in-dump-change-from-3-18-to-3-19

What is strange is that according to the release log, that options only apply 
to .dump; I would expect
that .mode insert also got an option similar to that, or perhaps a new .mode 
rawinsert
(in both cases the effect would be that the INSERT statements generated would 
keep
newlines and returns character verbatim).

Why would there be a way to modify the output of newlines & returns character 
in dump but not in .mod insert outputs?

Cheers.
--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Peter da Silva]

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 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 for internal performance optimizations.  At present the only 
optimization is to avoid using lookaside... etc.

Marc


-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Thursday, July 13, 2017 4:22 PM
To: SQLite mailing list 
    Subject: Re: [sqlite] Version 3.20.0 coming soon...

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 use it or 
> not?
>

That documentation is the contract of what  SQLITE_PREPARE_PERSISTENT is 
suppose to do, so it needs to be a little vague in order to allow for changes 
in the future.

In the current implementation, SQLITE_PREPARE_PERSISTENT avoids using 
lookaside memory to store pieces of the prepared statement, to avoid soaking up 
all of the fast lookaside memory and preventing it from being used for more 
useful things.  But the effect of SQLITE_PREPARE_PERSISTENT might change in 
future releases.  The key point (and the part of this interface that will not 
change) is that SQLITE_PREPARE_PERSISTENT is a hint to SQLite that the prepared 
statement is going to linger for a long time.

How would you recommend that be stated more clearly?

--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



Confidentiality notice: This e-mail is intended solely for use of the 
individual or entity to which it is addressed and may contain information that 
is proprietary, privileged, company confidential and/or exempt from disclosure 
under applicable law. If the reader is not the intended recipient or agent 
responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender by reply e-mail or collect telephone call 
and delete or destroy all copies of this e-mail message, any physical copies 
made of this e-mail message and/or any file attachment(s).
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

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 row, then it is certainly safe to close
the connection.  However, if you get multiple rows, that does not mean
it is unsafe.  Those extra entries might be prepared statements that
have been cached by extensions (ex: FTS5) that will be released
automatically when the connection is closed.

The purpose of the STMT virtual table is to help users debug the case
where sqlite3_close() returns SQLITE_BUSY.  Using the STMT virtual
tables, the developers can get a listing of unfinalized prepared
statements and quickly see which ones where overlooked.

While testing the STMT virtual table, we noticed that the cached
prepared statements from FTS5 were using up a lot of lookaside memory.
We had never noticed that before, and it is what prompted the
SQLITE_PREPARE_PERSISTENT enhancement.  So if the STMT table helped us
core developers to notice a problem in our own SQLite code, we figured
it would be good to publish it to perhaps help others notice subtle
problems in their code.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Simon Slavin]

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 
uncomfortable with a "magic" entity which isn’t clearly marked as not being 
part of your database.

Can I conclude that if "SELECT sql FROM STMT" returns no rows then closing the 
connection should work properly and immediately ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Marc L. Allen]

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 
for internal performance optimizations.  At present the only optimization is to 
avoid using lookaside... etc.

Marc


-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Thursday, July 13, 2017 4:22 PM
To: SQLite mailing list 
Subject: Re: [sqlite] Version 3.20.0 coming soon...

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 use it or 
> not?
>

That documentation is the contract of what  SQLITE_PREPARE_PERSISTENT is 
suppose to do, so it needs to be a little vague in order to allow for changes 
in the future.

In the current implementation, SQLITE_PREPARE_PERSISTENT avoids using lookaside 
memory to store pieces of the prepared statement, to avoid soaking up all of 
the fast lookaside memory and preventing it from being used for more useful 
things.  But the effect of SQLITE_PREPARE_PERSISTENT might change in future 
releases.  The key point (and the part of this interface that will not change) 
is that SQLITE_PREPARE_PERSISTENT is a hint to SQLite that the prepared 
statement is going to linger for a long time.

How would you recommend that be stated more clearly?

--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



Confidentiality notice: This e-mail is intended solely for use of the 
individual or entity to which it is addressed and may contain information that 
is proprietary, privileged, company confidential and/or exempt from disclosure 
under applicable law. If the reader is not the intended recipient or agent 
responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender by reply e-mail or collect telephone call 
and delete or destroy all copies of this e-mail message, any physical copies 
made of this e-mail message and/or any file attachment(s).
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

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
> use it or not?
>

That documentation is the contract of what  SQLITE_PREPARE_PERSISTENT
is suppose to do, so it needs to be a little vague in order to allow
for changes in the future.

In the current implementation, SQLITE_PREPARE_PERSISTENT avoids using
lookaside memory to store pieces of the prepared statement, to avoid
soaking up all of the fast lookaside memory and preventing it from
being used for more useful things.  But the effect of
SQLITE_PREPARE_PERSISTENT might change in future releases.  The key
point (and the part of this interface that will not change) is that
SQLITE_PREPARE_PERSISTENT is a hint to SQLite that the prepared
statement is going to linger for a long time.

How would you recommend that be stated more clearly?

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Dominique Pellé]

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 https://sqlite.org/draft/releaselog/3_20_0.html
>
> You can send issues to this email list, or directly to me.


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
use it or not?

Regards
Dominique
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

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
https://www.sqlite.org/releaselog/3_0_0.html) so I think I will leave
it.  All other fixes implemented.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[jungle Boogie]

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 overview of changes is at https://sqlite.org/draft/releaselog/3_20_0.html
>

https://sqlite.org/draft/c3ref/result_blob.html
Duplicate from:
space obtained from from sqlite3_malloc() before it

It's mighty impressive that you and your team make rather large
releases like this and you do it so frequently.
Tip of the hat to you!



> You can send issues to this email list, or directly to me.
>
> --
> D. Richard Hipp
> d...@sqlite.org


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[jungle Boogie]

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 overview of changes is at https://sqlite.org/draft/releaselog/3_20_0.html
>
> You can send issues to this email list, or directly to me.
>

On doesn't have to be capitalized:
SQLite Release 3.20.0 On 2017-07-20


Period missing on these items:
Added the STMT
Provide the SQLITE_PREPARE_PERSISTENT






> --
> D. Richard Hipp
> d...@sqlite.org


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

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 officially announced.
The code is still in the source tree but it is still unofficial and
experimental.

If you reload the change log, you will find that bullet is now missing.

I might add back a bullet about the code being present in the source
tree as "work-in-progress" and not for general consumption, yet.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Version 3.20.0 coming soon...

[David Raymond]

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 builts of" -> "in default builds of"

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Thursday, July 13, 2017 2:50 PM
To: General Discussion of SQLite Database
Subject: [sqlite] Version 3.20.0 coming soon...

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

You can send issues to this email list, or directly to me.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Version 3.20.0 coming soon...

[Richard Hipp]

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

You can send issues to this email list, or directly to me.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users