>
> There is no "year 0" between 1 BC and 1 AD. This is perhaps the most
> common fencepost problem in existance. The "great renaming" of AD to CE
> and doing away with BC by replacing them with "off by one" numbers less
> than 1 does not change the fact that there was, in fact, no year 0.
On 12/30/19 10:10 PM, Pierpaolo Bernardi wrote:
On Tue, Dec 31, 2019 at 4:07 AM Keith Medcalf wrote:
On Monday, 30 December, 2019 19:29, Michael Falconer
wrote:
As we approach the end of yet another year ( and indeed decade ).
Technically, every year is the end of a decade, if one means
On Tue, Dec 31, 2019 at 4:07 AM Keith Medcalf wrote:
>
>
> On Monday, 30 December, 2019 19:29, Michael Falconer
> wrote:
>
> > As we approach the end of yet another year ( and indeed decade ).
>
> Technically, every year is the end of a decade, if one means the immediately
> preceding ten
On Monday, 30 December, 2019 19:29, Michael Falconer
wrote:
> As we approach the end of yet another year ( and indeed decade ).
Technically, every year is the end of a decade, if one means the immediately
preceding ten years.
However, if you mean the end of the second decade of the 21st
On 31 Dec 2019, at 2:21am, Alexander Vega wrote:
> Could there be some compile time option to force Linux or Windows
> statically?
One of the problems with this is that there are a lot of utility libraries
built around SQLite. These are libraries provided for general-purpose use,
often a
Great work but pretty much what we have come to expect from DRH and the
SQLite team. As we approach the end of yet another year ( and indeed decade
) can I indulge the list in a simple congratulations to all involved and to
the outstanding support on offer when a member of this email list. SQLite
I watched the video and wondered about the virtual table calls within
sqlite as well. Without them you would have no VFS though... so they are
needed. Could there be some compile time option to force Linux or Windows
statically? Maybe.
I do not know the effect of collecting debug information
That's the total elapse time from me checking in a bug (check-in
https://www.sqlite.org/src/info/40d10e7aad5b8992) until Manuel
Rigger's fuzzer had located the bug and issued a ticket against it:
(ticket https://www.sqlite.org/src/info/892575cdba4e1e36).
Well, at least the bisect didn't take very
x, on Saturday, December 28, 2019 10:46 AM, wrote...
> Apologies if that’s not worded correctly. Scottish education could be
> done gooder
Wrong English! You should have said, "Scottish education could have been done
gooder." Com'on! This is not even my first language! :-)
josé
Bigthing Do, on Friday, December 27, 2019 01:56 PM, wrote...
>
> Dear sqlite developers:
>
> We met an accidental crash in sqlite with the following sample:
>
> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1
> ) SELECT col2 FROM table1 ORDER BY 1 ;
> WITH aaa AS ( SELECT
> On Dec 30, 2019, at 7:19 AM, Doug wrote:
>
> I am suggesting that if the we added the global calls to the underlying
> functions to the API - that is, the functions that are called by the function
> table indirection - then one could code the application to call the
> underlying
On 12/30/19 10:19 AM, Doug wrote:
OK, I get that the definition of the SQLite API is a (large) set of C function
calls. And that changing the way they work under the covers would break
something. (Check out the IDEA below!)
I'm wondering if your use case is - in the same application - that
On Wed, Dec 25, 2019 at 4:25 PM Richard Hipp wrote:
>
> The video provided details on what they did. I could not find any
> performance improvement by making mutexes direct calls instead of
> indirect calls.
This kind of optimization improves performance by reducing pressure on the
CPU's
OK, I get that the definition of the SQLite API is a (large) set of C function
calls. And that changing the way they work under the covers would break
something. (Check out the IDEA below!)
I'm wondering if your use case is - in the same application - that you
dynamically change from option
14 matches
Mail list logo
