Re: [sqlite] Date time input

>Because that's locale-dependent. Some countries, like the US, use >month/day/year; most other countries use day/month/year. Maybe. Canada supposedly uses the day/month/year format, or so I suddenly became aware of in 1998 when I was in my mid 30's. Prior to that day it was m/d/y. Then agai

Re: [sqlite] Date time input

> On Oct 7, 2019, at 6:17 AM, Jose Isaias Cabrera wrote: > > I have to ask this question: Why is it that the date function does not take > a '4/5/2019' and returns '2019-04-05'? Because that's locale-dependent. Some countries, like the US, use month/day/year; most other countries use day/m

Re: [sqlite] [patch] avoid dynamic alloc in vdbeSorterSort(...)

On Monday, 7 October, 2019 14:58, Dominique Pellé wrote: >Here the allocated size is fixed (always 64 pointers), so alloca does >not seem needed. >I wonder how many other functions could avoid dynamic allocation >like this one (either with a stack array or alloca). Probably a lot. I would no

Re: [sqlite] [patch] avoid dynamic alloc in vdbeSorterSort(...)

Here the allocated size is fixed (always 64 pointers), so alloca does not seem needed. I wonder how many other functions could avoid dynamic allocation like this one (either with a stack array or alloca). Regards Dominique On Mon, Oct 7, 2019 at 10:26 PM Mateusz Wajchęprzełóż wrote: > > What ab

Re: [sqlite] [patch] avoid dynamic alloc in vdbeSorterSort(...)

What about sqlite3StackAllocZero and SQLITE_USE_ALLOCA? pon., 7 paź 2019 o 20:51 Dominique Pellé napisał(a): > Hi > > Below is a patch which avoids a dynamic > allocation in vdbeSorterSort(...), using a local > stack array instead (faster and smaller code). > I assume that a local array of 64 po

[sqlite] [patch] avoid dynamic alloc in vdbeSorterSort(...)

Hi Below is a patch which avoids a dynamic allocation in vdbeSorterSort(...), using a local stack array instead (faster and smaller code). I assume that a local array of 64 pointers is small enough to be in the stack. Is this worth merging? $ fossil diff src/vdbesort.c Index: src/vdbesort.c ===

Re: [sqlite] Date time input

On 07 Oct 2019, at 17:19, Keith Medcalf wrote: > On Monday, 7 October, 2019 07:17, Jose Isaias Cabrera > wrote: > >>I have to ask this question: Why is it that the date function does not >>take a '4/5/2019' and returns '2019-04-05'? > > Because it does not. Humans read things in big endian o

Re: [sqlite] Date time input

Hi, Jose, Re: Wishing out loud. Maybe an implementation of sscanf() would be more useful generally. As to your date parsing problem, if you really insist on doing it in sql, you may already know how to accomplish it with something like the UPDATE below: .mode column .headers on create table t1

Re: [sqlite] Date time input

On 7 Oct 2019, at 2:17pm, Jose Isaias Cabrera wrote: > I have to ask this question: Why is it that the date function does not take > a '4/5/2019' and returns '2019-04-05'? Those are human formats. SQLite is a database management system. Its job is to store data and allow it to be recalled i

Re: [sqlite] Date time input

On Monday, 7 October, 2019 07:17, Jose Isaias Cabrera wrote: >I have to ask this question: Why is it that the date function does not >take a '4/5/2019' and returns '2019-04-05'? Because it does not. Humans read things in big endian order. For example, in the common base 10 system used eve

Re: [sqlite] Date time input

I had to deal with a similar conversion. I think the answer to why date() does not take other formats is simple: SQLite is minimalistic. This string processing can be done outside SQLite library. Minimalism of SQLite is one of the criteria for what gets implemented. It has few mathematical oper

Re: [sqlite] Copy-on-write VFS

On Monday, 7 October, 2019 03:16, Simon Slavin wrote: >> Given that we disable ceckpointing, can we assume that the main >> database-file will never be modified, and therefor could potentially be >> mounted read-only? No, and No. >You are correct that the WAL file contains database pages, rath

[sqlite] Date time input

Greetings. I have to ask this question: Why is it that the date function does not take a '4/5/2019' and returns '2019-04-05'? This may have been asked before, and the answer may be some where in the internet, but, I could not find it. The other thing is that it would be nice to have date ta

Re: [sqlite] Copy-on-write VFS

I'm aware that what I'm asking for is not be very portable between sql-engines, and that is fine. It does not affect core-product/value, just infrastructure. Also, this is about optimizing infrastructure work, so nice if it works, no biggi if it does not. But the thing we want to optimize is the s

Re: [sqlite] Copy-on-write VFS

On 7 Oct 2019, at 10:34am, Fredrik Larsen wrote: > In my head, checkpointing implies copying back all dirty-pages from the > WAL/COW-log to the main db-file. If we never checkpoint, the writes are still > completed, but lives in the WAL-file. We will offcourse merge back pages to > the main db

Re: [sqlite] Copy-on-write VFS

Hi Simon In my head, checkpointing implies copying back all dirty-pages from the WAL/COW-log to the main db-file. If we never checkpoint, the writes are still completed, but lives in the WAL-file. We will offcourse merge back pages to the main db-file, but this would be an offline process we start

Re: [sqlite] Copy-on-write VFS

On 7 Oct 2019, at 9:56am, Fredrik Larsen wrote: > nowhere does it warn about severe regression with > unbounded WAL-size [snip] There are tons of bad stuff the documentation doesn't warn you about. You might want to read agai

Re: [sqlite] Copy-on-write VFS

Interesting, I previously just assumed that WAL file stored a log of sql-like-update-statements since last checkpoint, making a large WAL-file effectivly unusable if you have any requirements on query-performance. But re-reading the WAL-documentation, there are references to "pages" being stored a