On 3/10/17, Dominique Devienne wrote:
>
> PS: The latter would be better than nothing (I mean in compiled ready to
> use form),
> if the former doesn't happen, as seems likely given the lack of response
> from DRH.
> (via the ML or the SQLite Fossil Timeline)
The SQLite
On Fri, Mar 10, 2017 at 12:29 PM, Stephan Buchert
wrote:
> There is extension-functions.c in
> http://sqlite.org/contrib/download/
> [...]
Is the suggestion to have sqrt, sin, cos, stdev, ... built into sqlite
> standalone, or to provide a more a obvious way to access the
as a scaler function,
but it does not appear to actually keep the two different definitions. Is this
a bug or working as intended?
> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of Richard Hipp
> Sent: Thursday, 9
On 3/9/17, Keith Medcalf wrote:
>
> note that fileio.c and shathree.c are inlined into shell.c, so in order to
> remove them I have to modify shell.c to ifdef them out when I am building.
>
Seriously? I have no trouble loading the external fileio.c and
shathree.c extensions
On Thu, Mar 9, 2017 at 6:05 PM, Keith Medcalf wrote:
> On Thursday, 9 March, 2017 07:30, Dominique Devienne
> wrote:
> > Last but not least, it's trivial to not use what's there and available
> and
> > easily disabled at compiled time, or ignored at
On Thursday, 9 March, 2017 07:30, Dominique Devienne
wrote:
> On Thu, Mar 9, 2017 at 3:05 PM, Keith Christian
> wrote:
> > At some point it's time to use a different database engine or offload
> > to other code. Sqlite could easily burgeon to
On Thu, 9 Mar 2017 10:45:36 +0100
Dominique Devienne wrote:
> I find that I'm often missing basic mathematical functions in the
> default shell.
$ sqlite3 -header <<< 'select typeof(1/0) as "how many";'
how many
null
Until SQLite deals with math as math, what is the point
On Thu, Mar 9, 2017 at 3:05 PM, Keith Christian
wrote:
> At some point it's time to use a different database engine or offload
> to other code. Sqlite could easily burgeon to the size of the other
> databases if everything asked for was included. Where, then, would
On Thu, Mar 9, 2017 at 2:49 PM, Eric Grange wrote:
> A bonus of having them defined in the core is that it avoids the minor
> inconsistencies that are bound to arise in custom implementations (starting
> with the name of math functions)
>
Yep.
> Main downside is probably
On Thu, Mar 9, 2017 at 3:04 PM, Jay Kreibich wrote:
> The main downside is that SQLite builds on a ton of platforms, including
> embedded devices. In some cases, those platforms don’t even support
> floating point numbers, never mind high-level math functions. It would add
> a
The main downside is that SQLite builds on a ton of platforms, including
embedded devices. In some cases, those platforms don’t even support floating
point numbers, never mind high-level math functions. It would add a mess of
new #defs.
There used to be a standard math extension that
We all know this but it bears repeating:
At some point it's time to use a different database engine or offload
to other code. Sqlite could easily burgeon to the size of the other
databases if everything asked for was included. Where, then, would we
get a small but still functional SQL engine?
A bonus of having them defined in the core is that it avoids the minor
inconsistencies that are bound to arise in custom implementations (starting
with the name of math functions)
Main downside is probably not going to be the size, but that it reserves
more names, and may conflict with existing
I second this - Been having a hard time making basic queries with a
simple x^y function in SQL for SQLite since there is no guarantee what
the end-user's system will have it compiled-in. I can version-check or
version-enforce easily, but compile-option check or enforce is a no-go.
If we can
14 matches
Mail list logo