On 6 Dec 2017, at 6:07pm, R Smith wrote:
> You mean make SQLite less Lite, but with Zero computational advantage, by
> simply adding syntactic sugar bloat? - I'm going to have to vote No on that.
> (Luckily my vote counts extremely little.)
I would normally vote with you,
On 2017/12/06 6:35 PM, Christian Schmitz wrote:
Actually, the left outer join is sufficient to execute all the outer
join operators:
- right outer join: just swap the "from" arguments
- full outer joins: union of left and right outer joins
Couldn’t SQLite implement that and do the swap for
>>
>>> Actually, the left outer join is sufficient to execute all the outer
>> join operators:
>>>
>>> - right outer join: just swap the "from" arguments
>>>
>>> - full outer joins: union of left and right outer joins
>>
Couldn’t SQLite implement that and do the swap for us?
As well as the
2017-12-06 15:46 GMT+01:00 Peter Da Silva :
> I’d recommend expr {double($temp)} so the bytecode compiler can optimize
> the expression.
>
> On 12/6/17, 8:40 AM, "sqlite-users on behalf of Cecil Westerhof" <
> sqlite-users-boun...@mailinglists.sqlite.org on behalf
I’d recommend expr {double($temp)} so the bytecode compiler can optimize the
expression.
On 12/6/17, 8:40 AM, "sqlite-users on behalf of Cecil Westerhof"
wrote:
return [expr double(${temp})]
2017-12-06 14:58 GMT+01:00 Simon Slavin :
>
>
> On 6 Dec 2017, at 1:19pm, Cecil Westerhof wrote:
>
> >message NOT NULL
>
> Given thqt you want the "message" stored as REAL, you should be defining
> this column as REAL. This is
Thanks all for the input. My knowledge from nearly 20 years ago is a bit
rusty when it came to material like this. Just adding "LEFT JOIN" instead
of just "JOIN" has my query working as I need it to. This type of result
set isn't something I regularly perform.
On Wed, Dec 6, 2017 at 4:41 AM,
On 6 Dec 2017, at 1:19pm, Cecil Westerhof wrote:
>message NOT NULL
Given thqt you want the "message" stored as REAL, you should be defining this
column as REAL. This is necessary, though not sufficient.
Simon.
2017-12-06 13:34 GMT+01:00 Darko Volaric :
> How it's stored depends on how the messages table is defined (which type
> the message column has been given), which you haven't shown, and whether
> storeMessage quotes the message argument when forming the string. My advice
> is to
How it's stored depends on how the messages table is defined (which type
the message column has been given), which you haven't shown, and whether
storeMessage quotes the message argument when forming the string. My advice
is to remove any column type and make sure numbers are not quoted when they
I just can't let some things go. I am such a bad boy.
See attachment. It has a great big TODO when working out BUILD_EXEEXT
that still needs implementing. Note that you need to change Makefile.in
as well to change "@TARGET_EXEEXT@" to "@EXEEXT@".
Tested as working on my system and
Trying to get it to work correctly:
BUILD_CC is correctly determined, but BUILD_EXEEXT is not (unless you
have a Cygwin system). On closer examination, the system is in fact
natively building lemon and mksourceid but because the extension is
wrong, you get an error like:
make: *** No
I have the following tcl script:
#!/usr/bin/env tclsh
### Improvements
# Get database from conf-file
package require sqlite3
proc getCPUTemp {} {
if {1 != [regexp -all -line {^CPU_TEMP: +\+([0-9.]+)°C } [exec
sensors] -> temp]} {
error {Did not get
On 6 Dec 2017, at 9:36am, Jean-Luc Hainaut wrote:
> Actually, the left outer join is sufficient to execute all the outer join
> operators:
>
> - right outer join: just swap the "from" arguments
>
> - full outer joins: union of left and right outer joins
I never
Actually, the left outer join is sufficient to execute all the outer
join operators:
- right outer join: just swap the "from" arguments
- full outer joins: union of left and right outer joins
Examples (classical "supplier-part-supply" example):
create table S(SN,NAME);
create table
Thanks for the reply.
To answer your question using autoconf/configure terminology, my build
system is Linux and my host system is MinGW32. That is I am building on
Linux to generate libraries/executables to run under MinGW (on Windows
essentially). I would however face exactly the same issue
On 12/6/17, Alastair Growcott wrote:
>
> To avoid confusion I recommend that you remove the option to
> cross-compile
I'm cool with that approach. Can you suggest a specific edit to the
configure.ac file that will accomplish what you describe?
>
> Also, I am not
17 matches
Mail list logo