Re: [sqlite] SQLite 3.22.0 coming soon

[curmudgeon]

8 d. Omit unused LEFT JOINs even if they are not the right-most joins of a
query. 

Thanks for fixing this. Working fine for me so far.



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.22.0 coming soon

[J Decker]

On Tue, Jan 9, 2018 at 12:30 PM, J Decker  wrote:

> swarmvtab3 test is still failing... (windows 10, msvc 2017)  10.0.16299.0
>
> swarmvtab3-1.2.3...
> Error: inconsistent ::dbcache and disk
> swarmvtab3-1.3.3...
> Error: inconsistent ::dbcache and disk
>
>
This works

>
> On Tue, Jan 9, 2018 at 11:46 AM, Simon Slavin 
> wrote:
>
>> On 9 Jan 2018, at 6:46pm, Richard Hipp  wrote:
>>
>> > The latest change summary can be seen at
>> > https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft
>>
>> In  …
>>
>> For "clobbering" use "overwriting", if only for the sake of international
>> readers.
>>
>> "If this option is pass a non-zero argument" should probably be "passed".
>>
>> I think you can come up with a more appropriate name than "expert".  How
>> about "cleverindex" or "indexwizard" or something.
>>
>> If this is easy to do, then for the .expert command and, by extension,
>> the external function …
>>
>> Please allow an option "—ignoreexisting" for the .expert command.  This
>> option makes SQLite ignore any existing indexes except for the ones which
>> implement primary keys.
>>
>> For extra points, with this option selected, in the output section, it
>> includes DROP INDEX commands for the indexes it ignored before the CREATE
>> INDEX command it prefers.
>>
>> For an additional bonus point, with this option selected, the command
>> should recognise when the new index it recommended is the same as one of
>> the existing indexes it ignored, and do the "no new indexes" thing.
>>
>> 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] SQLite 3.22.0 coming soon

[petern]

Richard. As you are probably already aware, I forgot about the encoding
column.  An encoding (UTF8,UTF16,...) column would also needed for the
PRAGMA function_list report to be the key for functions differing only by
the encoding flag:

https://sqlite.org/c3ref/create_function.html

One final issue.  Using the key columns discussed so far, functions
overriding builtin ones would appear in the PRAGMA report but subsequent
builtin overrides and non-builtin overrides can only be reported as the
most recent one.  Perhaps it would be better to have a module name column
instead of the existing builtin boolean column where the reserved module
name, call it 'sqlite', designates builtin entries.

Is {name, module, argcount, aggegate, encoding} a sufficient key to the
function description when special case builtins have the suggested
simulated entry(s)?

Peter








On Sat, Jan 13, 2018 at 12:15 PM, petern 
wrote:

> Single builtin functions that otherwise would have required two or more
> separate create_function calls should have two or more corresponding
> simulated entries for plain and aggregate flavors distinguishable by column
> values.max(A) aggregate and max(A,B,...) function could look something
> like this:
>
> name,builtin,aggregate,argcount
> max,1,1,1
> max,1,0,-1
>
> The arg_count column would simply be the nArg supplied (or as simulated)
> to sqlite3_create_function(..,int nArg,..). That is -1 for any number and 0
> to 127 for specific quantity. In case of coalesce(), argcount would have to
> be -1 but the description should say something about the minimum number of
> arguments - case in point about the need for descriptions.
>
> Are there other possibilities which wouldn't have a key?
>
> Peter
>
>
> On Fri, Jan 12, 2018 at 1:09 PM, Richard Hipp  wrote:
>
>> On 1/12/18, petern  wrote:
>> > Is adding arg_count and
>> > is_aggregate columns to PRAGMA function_list() on the roadmap?
>>
>> How would that work with functions like coalesce() and max() that take
>> an arbitrary number of arguments, or like max() that is an aggregate
>> with one argument and a scalar with two or more arguments?
>>
>> --
>> 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] SQLite 3.22.0 coming soon

[petern]

Single builtin functions that otherwise would have required two or more
separate create_function calls should have two or more corresponding
simulated entries for plain and aggregate flavors distinguishable by column
values.max(A) aggregate and max(A,B,...) function could look something
like this:

name,builtin,aggregate,argcount
max,1,1,1
max,1,0,-1

The arg_count column would simply be the nArg supplied (or as simulated) to
sqlite3_create_function(..,int nArg,..). That is -1 for any number and 0 to
127 for specific quantity. In case of coalesce(), argcount would have to be
-1 but the description should say something about the minimum number of
arguments - case in point about the need for descriptions.

Are there other possibilities which wouldn't have a key?

Peter


On Fri, Jan 12, 2018 at 1:09 PM, Richard Hipp  wrote:

> On 1/12/18, petern  wrote:
> > Is adding arg_count and
> > is_aggregate columns to PRAGMA function_list() on the roadmap?
>
> How would that work with functions like coalesce() and max() that take
> an arbitrary number of arguments, or like max() that is an aggregate
> with one argument and a scalar with two or more arguments?
>
> --
> 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] SQLite 3.22.0 coming soon

[Richard Hipp]

On 1/12/18, petern  wrote:
> Is adding arg_count and
> is_aggregate columns to PRAGMA function_list() on the roadmap?

How would that work with functions like coalesce() and max() that take
an arbitrary number of arguments, or like max() that is an aggregate
with one argument and a scalar with two or more arguments?

-- 
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] SQLite 3.22.0 coming soon

[petern]

This is premature of course.  The columns of the current PRAGMA
function_list() report do not form a practical key for functions.
Additional columns arg_count and is_aggregate would be needed  join PRAGMA
function_list() with a function description table.

Suggestion: As an example of both testing the new zipfile facility and
introspection, SQLite core built-in descriptions could be published as a
zip file which joins properly with a newly sufficient PRAGMA
function_list().

So, now the more precisely relevant question is:   Is adding arg_count and
is_aggregate columns to PRAGMA function_list() on the roadmap?

With that change alone, at least extension implementors would have a way to
publish PRAGMA interactive function argument descriptions.

Richard?



On Fri, Jan 12, 2018 at 8:47 AM, petern  wrote:

> Ryan.  The core and sqlite3_create_function...() needn't be burdened at
> all except to store some very basic description strings as a compile time
> option.
>
> PRAGMA function_list() cold gather descriptions on the fly by:
>
> 1. Spinning through the list of registered %_function_description(F,N)
> functions for each row, or
>
> 2. Spinning through a list of library module exports, say
> sqlite3__function_description(F,N).
>
> Modules implementing either interface could do so trivially with if
> statements or with a binary search of hand sorted description array.
>
> This enhancement is feasible, easy to implement, and would help
> tremendously to see exactly how to call any function from the command line.
>
> My question mainly was to find out if the idea was considered and if it is
> on the roadmap along with the SQLITE_INTROSPECTION_PRAGMAS change.
>
> Peter
>
>
> On Thu, Jan 11, 2018 at 2:31 PM, R Smith  wrote:
>
>>
>> On 2018/01/11 8:11 PM, petern wrote:
>>
>>> With SQLITE_INTROSPECTION_PRAGMAS turned on, is a function description on
>>> the roadmap?
>>> It would be very helpful to expose a short description of function
>>> arguments.
>>>
>>> Implementation suggestion: a new trailing argument "description" on
>>> sqlite3_create_function() or sqlite3_create_function_v2()
>>> and corresponding description column in the PRAGMA function_list report.
>>>
>>
>> Well, I like the idea.
>>
>> For one, it would allow an easy to read updated description for those of
>> us who maintain SQLite management tools and connectors... but accessing the
>> web is more or less equally simple, though a direct api would be nice too.
>> Maybe this would better serve add-on libraries and UDFs since those
>> function descriptions are not typically available on the web, and certainly
>> not on the standard sqlite site.
>>
>> The only con I'm seeing is the extra disk/memory footprint for what is
>> essentially comments and can (especially for the standard functions) be
>> found easily at: https://sqlite.org/lang_corefunc.html
>>
>> Perhaps there is another benefit I'm not yet seeing that would better
>> merit paying said resource cost - if so, I'm eager to hear it.
>>
>> Cheers,
>> Ryan
>>
>> ___
>> 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] SQLite 3.22.0 coming soon

[petern]

Ryan.  The core and sqlite3_create_function...() needn't be burdened at all
except to store some very basic description strings as a compile time
option.

PRAGMA function_list() cold gather descriptions on the fly by:

1. Spinning through the list of registered %_function_description(F,N)
functions for each row, or

2. Spinning through a list of library module exports, say
sqlite3__function_description(F,N).

Modules implementing either interface could do so trivially with if
statements or with a binary search of hand sorted description array.

This enhancement is feasible, easy to implement, and would help
tremendously to see exactly how to call any function from the command line.

My question mainly was to find out if the idea was considered and if it is
on the roadmap along with the SQLITE_INTROSPECTION_PRAGMAS change.

Peter


On Thu, Jan 11, 2018 at 2:31 PM, R Smith  wrote:

>
> On 2018/01/11 8:11 PM, petern wrote:
>
>> With SQLITE_INTROSPECTION_PRAGMAS turned on, is a function description on
>> the roadmap?
>> It would be very helpful to expose a short description of function
>> arguments.
>>
>> Implementation suggestion: a new trailing argument "description" on
>> sqlite3_create_function() or sqlite3_create_function_v2()
>> and corresponding description column in the PRAGMA function_list report.
>>
>
> Well, I like the idea.
>
> For one, it would allow an easy to read updated description for those of
> us who maintain SQLite management tools and connectors... but accessing the
> web is more or less equally simple, though a direct api would be nice too.
> Maybe this would better serve add-on libraries and UDFs since those
> function descriptions are not typically available on the web, and certainly
> not on the standard sqlite site.
>
> The only con I'm seeing is the extra disk/memory footprint for what is
> essentially comments and can (especially for the standard functions) be
> found easily at: https://sqlite.org/lang_corefunc.html
>
> Perhaps there is another benefit I'm not yet seeing that would better
> merit paying said resource cost - if so, I'm eager to hear it.
>
> Cheers,
> Ryan
>
> ___
> 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] SQLite 3.22.0 coming soon

[R Smith]

On 2018/01/11 8:11 PM, petern wrote:

With SQLITE_INTROSPECTION_PRAGMAS turned on, is a function description on
the roadmap?
It would be very helpful to expose a short description of function
arguments.

Implementation suggestion: a new trailing argument "description" on
sqlite3_create_function() or sqlite3_create_function_v2()
and corresponding description column in the PRAGMA function_list report.


Well, I like the idea.

For one, it would allow an easy to read updated description for those of 
us who maintain SQLite management tools and connectors... but accessing 
the web is more or less equally simple, though a direct api would be 
nice too.
Maybe this would better serve add-on libraries and UDFs since those 
function descriptions are not typically available on the web, and 
certainly not on the standard sqlite site.


The only con I'm seeing is the extra disk/memory footprint for what is 
essentially comments and can (especially for the standard functions) be 
found easily at: https://sqlite.org/lang_corefunc.html


Perhaps there is another benefit I'm not yet seeing that would better 
merit paying said resource cost - if so, I'm eager to hear it.


Cheers,
Ryan

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

Re: [sqlite] SQLite 3.22.0 coming soon

[petern]

Or, more practically, please consider a virtual style API where PRAGMA
function_list() gathers function description strings from all registered 2
argument functions named like %_function_description(F,N) where F is the
function name and N is the argument count.

A good example implementation might be a function called
sqlite3_function_description(F,N) which returns short argument descriptions
of all builtin functions - possibly derived from the build process.

Peter






On Thu, Jan 11, 2018 at 10:11 AM, petern 
wrote:

> With SQLITE_INTROSPECTION_PRAGMAS turned on, is a function description on
> the roadmap?
> It would be very helpful to expose a short description of function
> arguments.
>
> Implementation suggestion: a new trailing argument "description" on
> sqlite3_create_function() or sqlite3_create_function_v2()
> and corresponding description column in the PRAGMA function_list report.
>
>
>
> On Tue, Jan 9, 2018 at 5:06 PM, Richard Hipp  wrote:
>
>> All of the minor issues mentioned by prior emails in this thread
>> should now be fixed.  Thanks to everybody for proof-reading and
>> testing!
>>
>> Fresh source code is now available on trunk
>> (https://sqlite.org/src/info/trunk) and from the "Prerelease Snapshot"
>> link on the https://sqlite.org/download.html page if you would like to
>> continue testing.
>>
>> We are not yet at "pencils down".  More enhancements may yet go into
>> this release before we start our final release testing.  Nevertheless,
>> the community testing you have conducted so far has found several real
>> issues, and is greatly appreciated.  Please continue the good work!
>> --
>> 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] SQLite 3.22.0 coming soon

[petern]

With SQLITE_INTROSPECTION_PRAGMAS turned on, is a function description on
the roadmap?
It would be very helpful to expose a short description of function
arguments.

Implementation suggestion: a new trailing argument "description" on
sqlite3_create_function() or sqlite3_create_function_v2()
and corresponding description column in the PRAGMA function_list report.



On Tue, Jan 9, 2018 at 5:06 PM, Richard Hipp  wrote:

> All of the minor issues mentioned by prior emails in this thread
> should now be fixed.  Thanks to everybody for proof-reading and
> testing!
>
> Fresh source code is now available on trunk
> (https://sqlite.org/src/info/trunk) and from the "Prerelease Snapshot"
> link on the https://sqlite.org/download.html page if you would like to
> continue testing.
>
> We are not yet at "pencils down".  More enhancements may yet go into
> this release before we start our final release testing.  Nevertheless,
> the community testing you have conducted so far has found several real
> issues, and is greatly appreciated.  Please continue the good work!
> --
> 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] SQLite 3.22.0 coming soon

[Gwendal Roué]

No more glitch with sqlite3_column_name :-)

Thanks Richard,
Gwendal

> Le 10 janv. 2018 à 02:06, Richard Hipp  a écrit :
> 
> All of the minor issues mentioned by prior emails in this thread
> should now be fixed.  Thanks to everybody for proof-reading and
> testing!
> 
> Fresh source code is now available on trunk
> (https://sqlite.org/src/info/trunk) and from the "Prerelease Snapshot"
> link on the https://sqlite.org/download.html page if you would like to
> continue testing.
> 
> We are not yet at "pencils down".  More enhancements may yet go into
> this release before we start our final release testing.  Nevertheless,
> the community testing you have conducted so far has found several real
> issues, and is greatly appreciated.  Please continue the good work!
> -- 
> 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] SQLite 3.22.0 coming soon

[Richard Hipp]

On 1/9/18, E.Pasma  wrote:
> Dear SQLite developers and eventual PowerPC users,
> using a likely outdated compiler:
>   powerpc-apple-darwin9-gcc-4.0.1
> a compile error occors:
>   shell.c:10062: error: conflicting types for ‘integerValue’
>   shell.c:9169: error: previous implicit declaration of ‘integerValue’

This seems like a compiler bug.  But it is easy enough to work around,
and that is what I have done.  Please verify that the latest trunk
code (or the latest "prerelease-snapshot") is now working for you on
your old PowerPC system.  Thanks!

This is the kind of thing is very important.  We SQLite developers can
test as much as we want to, but we will never find strange
interactions with old compilers that we don't own.  This is exactly
the kind of thing we need your help with.  Thanks for all your
testing!

-- 
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] SQLite 3.22.0 coming soon

[E.Pasma]

Dear SQLite developers and eventual PowerPC users,
using a likely outdated compiler:
powerpc-apple-darwin9-gcc-4.0.1
a compile error occors:
shell.c:10062: error: conflicting types for ‘integerValue’
	shell.c:9169: error: previous implicit declaration of ‘integerValue’  
was here
it is still to overcome by an explicit declaration of IntegerValue  
before expertDotCommand.
This must be be the only place where this order of reference and  
definition occurs. Is that alright?

Thanks, E. Pasma

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

Re: [sqlite] SQLite 3.22.0 coming soon

[J Decker]

On Tue, Jan 9, 2018 at 1:19 PM, Gwendal Roué  wrote:

>
> > Le 9 janv. 2018 à 21:47, Richard Hipp  a écrit :
> >
> > On 1/9/18, Gwendal Roué  wrote:
> >> 1. For statements made of parameters, such as `SELECT ?, ?` or `SELECT
> :a,
> >> :b`, the sqlite3_column_name used to return the parameter name ("?" or
> ":a"
> >> etc.) for all parameters, the last one included. The latest version
> returns
> >> an empty string for the last parameter.
> >
> > I have not been able to reproduce this problem using the command-line
> > shell.  I tried the following script:
> >
> >  .header on
> >  SELECT ?, ?;
> >  SELECT :a, :b;
> >
> > It shows me the correct column names for all columns.  Do you have a
> > reproducible test case that I can work from?
>
> I have Swift code which reliably reproduces the bug :
>
> var conn: OpaquePointer? = nil
> sqlite3_open_v2("", , SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE,
> nil)
> var stmt: OpaquePointer? = nil
> sqlite3_prepare_v3(conn, "SELECT :a, :b", -1, 0, , nil)
> sqlite3_column_name(stmt, 0) // ":a"
> sqlite3_column_name(stmt, 1) // ""
>
> A manual translation into C gives:
>
> void *conn, *stmt;
> sqlite3_open_v2("", , SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE,
> NULL);
> sqlite3_prepare_v3(conn, "SELECT :a, :b", -1, 0, , NULL);
> sqlite3_column_name(stmt, 0); // ":a"
> sqlite3_column_name(stmt, 1); // ""
>
>
was also able reproduce it with regular C.


> If this is a side effect of the Swift C, we have found another interesting
> bug, but not in SQLite :-)
>
> Gwendal
>
> ___
> 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] SQLite 3.22.0 coming soon

[Gwendal Roué]

> Le 9 janv. 2018 à 21:47, Richard Hipp  a écrit :
> 
> On 1/9/18, Gwendal Roué  wrote:
>> 1. For statements made of parameters, such as `SELECT ?, ?` or `SELECT :a,
>> :b`, the sqlite3_column_name used to return the parameter name ("?" or ":a"
>> etc.) for all parameters, the last one included. The latest version returns
>> an empty string for the last parameter.
> 
> I have not been able to reproduce this problem using the command-line
> shell.  I tried the following script:
> 
>  .header on
>  SELECT ?, ?;
>  SELECT :a, :b;
> 
> It shows me the correct column names for all columns.  Do you have a
> reproducible test case that I can work from?

I have Swift code which reliably reproduces the bug :

var conn: OpaquePointer? = nil
sqlite3_open_v2("", , SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE, nil)
var stmt: OpaquePointer? = nil
sqlite3_prepare_v3(conn, "SELECT :a, :b", -1, 0, , nil)
sqlite3_column_name(stmt, 0) // ":a"
sqlite3_column_name(stmt, 1) // ""

A manual translation into C gives:

void *conn, *stmt;
sqlite3_open_v2("", , SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE, 
NULL);
sqlite3_prepare_v3(conn, "SELECT :a, :b", -1, 0, , NULL);
sqlite3_column_name(stmt, 0); // ":a"
sqlite3_column_name(stmt, 1); // ""

If this is a side effect of the Swift C, we have found another interesting bug, 
but not in SQLite :-)

Gwendal

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

Re: [sqlite] SQLite 3.22.0 coming soon

[Richard Hipp]

On 1/9/18, Gwendal Roué  wrote:
> 1. For statements made of parameters, such as `SELECT ?, ?` or `SELECT :a,
> :b`, the sqlite3_column_name used to return the parameter name ("?" or ":a"
> etc.) for all parameters, the last one included. The latest version returns
> an empty string for the last parameter.

I have not been able to reproduce this problem using the command-line
shell.  I tried the following script:

  .header on
  SELECT ?, ?;
  SELECT :a, :b;

It shows me the correct column names for all columns.  Do you have a
reproducible test case that I can work from?
-- 
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] SQLite 3.22.0 coming soon

[J Decker]

swarmvtab3 test is still failing... (windows 10, msvc 2017)  10.0.16299.0

swarmvtab3-1.2.3...
Error: inconsistent ::dbcache and disk
swarmvtab3-1.3.3...
Error: inconsistent ::dbcache and disk


On Tue, Jan 9, 2018 at 11:46 AM, Simon Slavin  wrote:

> On 9 Jan 2018, at 6:46pm, Richard Hipp  wrote:
>
> > The latest change summary can be seen at
> > https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft
>
> In  …
>
> For "clobbering" use "overwriting", if only for the sake of international
> readers.
>
> "If this option is pass a non-zero argument" should probably be "passed".
>
> I think you can come up with a more appropriate name than "expert".  How
> about "cleverindex" or "indexwizard" or something.
>
> If this is easy to do, then for the .expert command and, by extension, the
> external function …
>
> Please allow an option "—ignoreexisting" for the .expert command.  This
> option makes SQLite ignore any existing indexes except for the ones which
> implement primary keys.
>
> For extra points, with this option selected, in the output section, it
> includes DROP INDEX commands for the indexes it ignored before the CREATE
> INDEX command it prefers.
>
> For an additional bonus point, with this option selected, the command
> should recognise when the new index it recommended is the same as one of
> the existing indexes it ignored, and do the "no new indexes" thing.
>
> 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] SQLite 3.22.0 coming soon

[Gwendal Roué]

Hello,

I could spot two behavior changes in f6355970 while testing GRDB.swift.

1. For statements made of parameters, such as `SELECT ?, ?` or `SELECT :a, :b`, 
the sqlite3_column_name used to return the parameter name ("?" or ":a" etc.) 
for all parameters, the last one included. The latest version returns an empty 
string for the last parameter.

2. '^foo' used to be an invalid FTS5 pattern. It is valid in the latest version 
(but I did not check its behavior).

Cheers,
Gwendal Roué

> Le 9 janv. 2018 à 19:46, Richard Hipp  a écrit :
> 
> Version 3.22.0 will probably be released soon.  Your help in
> beta-testing is appreciated.  Please download the latest "trunk"
> sources (from https://sqlite.org/src/info/trunk) or a pre-release
> snapshot (the top-most link at https://sqlite.org/download.html) and
> verify that you are able to build and use the latest code in your
> applications.  Report any issues to this mailing list, or directly to
> me.
> 
> The latest change summary can be seen at
> https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft
> 3.22.0 webpage is at https://www.sqlite.org/draft
> 
> Detailed log of all check-ins since the last release:
> https://www.sqlite.org/src/timeline?from=release=trunk
> 
> -- 
> 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] SQLite 3.22.0 coming soon

[Simon Slavin]

On 9 Jan 2018, at 6:46pm, Richard Hipp  wrote:

> The latest change summary can be seen at
> https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft

In  …

For "clobbering" use "overwriting", if only for the sake of international 
readers.

"If this option is pass a non-zero argument" should probably be "passed".

I think you can come up with a more appropriate name than "expert".  How about 
"cleverindex" or "indexwizard" or something.

If this is easy to do, then for the .expert command and, by extension, the 
external function …

Please allow an option "—ignoreexisting" for the .expert command.  This option 
makes SQLite ignore any existing indexes except for the ones which implement 
primary keys.

For extra points, with this option selected, in the output section, it includes 
DROP INDEX commands for the indexes it ignored before the CREATE INDEX command 
it prefers.

For an additional bonus point, with this option selected, the command should 
recognise when the new index it recommended is the same as one of the existing 
indexes it ignored, and do the "no new indexes" thing.

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

Re: [sqlite] SQLite 3.22.0 coming soon

[David Raymond]

Oh sweet, zipfile extension.


Small typo fixes:

In https://www.sqlite.org/draft/rtree.html#rtreecheck
"on the rtree table named R containing in database S."
should be
"on the rtree table named R contained in database S."

https://www.sqlite.org/draft/cli.html#expert
"If this option is pass a non-zero argument"
should be
"If this option is passed a non-zero argument"


-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Richard Hipp
Sent: Tuesday, January 09, 2018 1:46 PM
To: General Discussion of SQLite Database
Subject: [sqlite] SQLite 3.22.0 coming soon

Version 3.22.0 will probably be released soon.  Your help in
beta-testing is appreciated.  Please download the latest "trunk"
sources (from https://sqlite.org/src/info/trunk) or a pre-release
snapshot (the top-most link at https://sqlite.org/download.html) and
verify that you are able to build and use the latest code in your
applications.  Report any issues to this mailing list, or directly to
me.

The latest change summary can be seen at
https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft
3.22.0 webpage is at https://www.sqlite.org/draft

Detailed log of all check-ins since the last release:
https://www.sqlite.org/src/timeline?from=release=trunk

-- 
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] SQLite 3.22.0 coming soon

[Donald Griggs]

In an attempt to be helpful, two possible typos are:

https://www.sqlite.org/draft/cli.html#expert

 If this option is pass a non-zero argument  [change pass -> passed]



https://www.sqlite.org/draft/releaselog/3_22_0.html

 A complex result set bias the decision

 Maybe " A complex result biases the decision"

 Or " A complex result set biases the decision"



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