SQLite 3.22.0 coming soon

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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_<module>_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 <[hidden email]> 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
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite 3.22.0 coming soon

Richard Hipp-3
On 1/12/18, petern <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: EXTERNAL: SQLite 3.22.0 coming soon

Wolfgang Enzinger
In reply to this post by Edwards, Mark C.
Am Wed, 10 Jan 2018 02:25:35 +0000 schrieb Edwards, Mark C.:

> Release mode/x86 Visual Studio 2015 Pro....no problems with the new snapshot

Same here with my ancient Visual Studio 2005. :-)

Cheers Wolfgang

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite 3.22.0 coming soon

petern
In reply to this post by Richard Hipp-3
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 <[hidden email]> wrote:

> On 1/12/18, petern <[hidden email]> 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
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
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 <[hidden email]> wrote:
>
>> On 1/12/18, petern <[hidden email]> 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
>> [hidden email]
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite 3.22.0 coming soon

J Decker
In reply to this post by J Decker
On Tue, Jan 9, 2018 at 12:30 PM, J Decker <[hidden email]> 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 <[hidden email]>
> wrote:
>
>> On 9 Jan 2018, at 6:46pm, Richard Hipp <[hidden email]> wrote:
>>
>> > The latest change summary can be seen at
>> > https://www.sqlite.org/draft/releaselog/3_22_0.html and the draft
>>
>> In <https://www.sqlite.org/draft/cli.html#expert> …
>>
>> 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
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: SQLite 3.22.0 coming soon

curmudgeon
In reply to this post by Richard Hipp-3
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12