On 14 Dec 2019, at 11:16pm, Yongheng Chen wrote:
> When we report the bugs, we said that they were from 3.31 version, but people
> in mitre changed them to 3.30.1. We just reported what we found. And the
> commit we reported in the bug report is referencing to the official GitHub
> repo.
>
When we report the bugs, we said that they were from 3.31 version, but people
in mitre changed them to 3.30.1. We just reported what we found. And the commit
we reported in the bug report is referencing to the official GitHub repo.
Bugs are found in the latest version, because there are so
On 12/14/19, Raitses, Alex wrote:
> Hello,
> CVE-2019-19317 (https://nvd.nist.gov/vuln/detail/CVE-2019-19317) was
> submitted on SQLite.
> As far as I can see the patch is already submitted. Can you confirm please?
> Do you have estimation for the fixed version release?
This CVE appears to
Addendum: I suspect it's the one mentioned as being filed in this earlier
thread:
https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg117794.html
On Sat, Dec 14, 2019, 2:12 PM Shawn Wagner wrote:
> This appears to be a CVE pertaining to a feature that hasn't even been
>
This appears to be a CVE pertaining to a feature that hasn't even been
released yet (generated columns will be in the upcoming 3.31; they're
certainly not in the referenced 3.30.1). Unless you're using the
development snapshot from the download page or following trunk on fossil
and haven't updated
Hello,
CVE-2019-19317 (https://nvd.nist.gov/vuln/detail/CVE-2019-19317) was submitted
on SQLite.
As far as I can see the patch is already submitted. Can you confirm please?
Do you have estimation for the fixed version release?
Thanks in advance,
Regards,
Alex
On 14 Dec 2019, at 8:49pm, Donald Shepherd wrote:
> Gut feel is that the divide will fall such that embedded use cases want the
> memory and PC or equivalent use cases want the CPU.
I read here around 18 months ago that more than half of SQLite installations
were on mobile phones (presumably
On 12/14/19 1:55 PM, František Kučera wrote:
> Dne 14. 12. 19 v 18:20 Richard Damon napsal(a):
>> What he wants is different. He takes a basically arbitrary database
>> (user provided) and an arbitrary SQL statement (also user provided) and
>> he wants to determine what type a given column will
While I am using SQLIite mostly in x86-64 with plentiful RAM, I suspect the
reduced lookaside size will help CPU L1/L2 caches, which is definitely
never plentiful. I would not be surprised if it resulted in a speedup in
practical high-load multi-threaded scenarios.
Also future SQLite code changes
On Sun, 15 Dec 2019 at 1:40 am, Dominique Pellé
wrote:
> Richard Hipp wrote:
>
> > On 12/14/19, Dominique Pellé wrote:
> > >
> > > I'm curious about what kind of change reduces memory per
> > > connection.
> > >
> >
> > The branch is here:
>
On 14 Dec 2019, at 6:55pm, František Kučera wrote:
> This is IMHO feasible, but would mean probably a lot of work. However it
> might be beneficial for those who come from other relational databases and
> prefer static typing rather than dynamic.
I don't think it's practical. For instance,
I just don't see the trouble
https://github.com/d3x0r/SACK/blob/master/src/SQLlib/sqlstub.c#L3613-L3680
for each row for each column
= sqlite3_column_type( collection->stmt, idx - 1 )
and then get the data according to the type... sqlite3_column_double (for
instance)
It's not very expensive to
Dne 14. 12. 19 v 18:20 Richard Damon napsal(a):
> What he wants is different. He takes a basically arbitrary database
> (user provided) and an arbitrary SQL statement (also user provided) and
> he wants to determine what type a given column will present.
Yes, I am looking for something that is
On 12/14/19 11:12 AM, Simon Slavin wrote:
> On 14 Dec 2019, at 10:46am, František Kučera wrote:
>
>> SELECT cast(dump+100 AS integer) FROM fstab;
>>
>> the sqlite3_column_decltype() still does not return the integer type.
>>
>> Would it be possible to modify this function or add a new one, to
On 14 Dec 2019, at 10:46am, František Kučera wrote:
> SELECT cast(dump+100 AS integer) FROM fstab;
>
> the sqlite3_column_decltype() still does not return the integer type.
>
> Would it be possible to modify this function or add a new one, to tell the
> correct type at least if there is an
Richard Hipp wrote:
> On 12/14/19, Dominique Pellé wrote:
> >
> > I'm curious about what kind of change reduces memory per
> > connection.
> >
>
> The branch is here:
> https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2
>
> I'll try to add more description later - busy with other
I think it should be turned on by default. Saving 72KB per connection is
worth the performance penalty.
On Sat, Dec 14, 2019 at 11:22 AM Dominique Pellé
wrote:
> Richard Hipp wrote:
>
> > A new feature on a branch has the following disadvantages:
> >
> > (1) It uses about 0.25% more CPU
On 12/14/19, Richard Hipp wrote:
> On 12/14/19, Dominique Pellé wrote:
>>
>> I'm curious about what kind of change reduces memory per
>> connection.
>>
>
> The branch is here:
> https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2
>
> I'll try to add more description later - busy with
On 12/14/19, Dominique Pellé wrote:
>
> I'm curious about what kind of change reduces memory per
> connection.
>
The branch is here: https://www.sqlite.org/src/timeline?r=mini-lookaside-take-2
I'll try to add more description later - busy with other things right
this moment.
--
D. Richard Hipp
On 12/14/19 5:22 AM, František Kučera wrote:
> Dne 14. 12. 19 v 9:36 Darren Duncan napsal(a):
>> With respect to SQLite, every column is the union of: Null, every Integer,
>> every Float, every Text, every Blob.
> OK, we can close this thread with that it is currently impossible to track
> the
Richard Hipp wrote:
> A new feature on a branch has the following disadvantages:
>
> (1) It uses about 0.25% more CPU cycles. (Each release of SQLite is
> normally about 0.5% faster, so enabling this feature is sort of like
> going back by one-half of a release cycle.)
>
> (2) The code space
On 15/12/2019 00:27, Richard Hipp wrote:
A new feature on a branch has the following disadvantages:
(1) It uses about 0.25% more CPU cycles. (Each release of SQLite is
normally about 0.5% faster, so enabling this feature is sort of like
going back by one-half of a release cycle.)
(2) The
Hi Richard,
I can see the advantage of both, but personally I prefer the greater
speed with slightly more memory approach (e.g. what we have now).
Kind regards,
Philip Bennefall
On 12/14/2019 2:27 PM, Richard Hipp wrote:
A new feature on a branch has the following disadvantages:
(1)
A new feature on a branch has the following disadvantages:
(1) It uses about 0.25% more CPU cycles. (Each release of SQLite is
normally about 0.5% faster, so enabling this feature is sort of like
going back by one-half of a release cycle.)
(2) The code space (the size of the library) is
dump+100 (string), pass+1000 (string)
the type information disappears and former integers becomes mere strings
There must be something else going on here:
Z:> sqlite3
SQLite version 3.30.1 2019-10-10 20:19:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use
P.S. Even if I do:
SELECT cast(dump+100 AS integer) FROM fstab;
the sqlite3_column_decltype() still does not return the integer type.
Would it be possible to modify this function or add a new one, to tell the
correct type at least if there is an explicit cast like this in given query?
If I
Dne 14. 12. 19 v 9:36 Darren Duncan napsal(a):
> With respect to SQLite, every column is the union of: Null, every Integer,
> every Float, every Text, every Blob.
OK, we can close this thread with that it is currently impossible to track the
declared column types through relational operations.
František,
Having done this myself, I will tell you that:
The only effective design for your "generic software that should work with any
database model" is that every column is the universal type, the union of all
other types; the type is the set of all representable values.
With respect to
28 matches
Mail list logo
