Fred Williams wrote:
>
> Well, since you put it that way. May I go one step farther and request
> that this new Dynamic Type also adhere to "Bankers Rounding" commonly
> implemented as BCD in other so equipped databases.
>
> For years I have spent countless hours testing and sweating rounding
>
> If I designed a sqlite database to be used by a bunch of independent
> applications, for example a bunch of CGI scripts each of which
> opened the database, did some processing, and exited, would
> that be (a) safe (b) effecient ?
I think lots of people have used that pattern successfully.
I can think of a very elegant solution to this whole ordeal, which is
inspired by Perl's way of doing things: Have *two* division
operators which have different behaviour and which look different so
you can tell what will happen where they are used, regardless of
their operand data types. Per
Edward Wilson wrote:
What I was trying to say was: with other db products the drivers (or something
somewhere)
calculated the number of rows returned in a query automagicly. I have never
had to do anything
'extra' to get the number of rows in a query other than
resultset-object.rowcout - 'row
[EMAIL PROTECTED] wrote:
I admit that it has been 4 decades since I was in grade school,
but back in the 60's we were taught that 5/2 is 2.5. Are they
teaching something different now? Or have I misunderstood the
comment?
Ah, but how does the 5 *feel* about being divided by 2 ? is the
John Stanton <[EMAIL PROTECTED]> wrote:
>
> Users love such a number system because it is natural and works like the
> Arithmetic they learned in Grade School.
>
> I find the idea of dividing two integers stored in binary form and
> getting a gratuitous conversion to floating point ugly and pot
Ditto - sqlite is pure beauty - thanks.
--- Clay Dowling <[EMAIL PROTECTED]> wrote:
> Amid all the wailing and gnashing of teeth I thought that I'd just say
> thanks for making a great embeddable database that puts a very minimal
> burden on the developer. My product, at least, would never have
Rather than get caught in a mess of integers and floating point numbers
and the consequent unpredictable results, how about having some typing,
such as integers and floats and also a decimal fixed point type which
looks like a text field and displays like one but which is much more
compatible w
If I designed a sqlite database to be used by a bunch of independent
applications, for example a bunch of CGI scripts each of which
opened the database, did some processing, and exited, would
that be (a) safe (b) effecient ?
Amid all the wailing and gnashing of teeth I thought that I'd just say
thanks for making a great embeddable database that puts a very minimal
burden on the developer. My product, at least, would never have seen
the light of day without SQLite. I intend to continue using SQLite into
the future
What I was trying to say was: with other db products the drivers (or something
somewhere)
calculated the number of rows returned in a query automagicly. I have never
had to do anything
'extra' to get the number of rows in a query other than
resultset-object.rowcout - 'rowcout' being
whatever th
* Toby Allsopp:
> On 30 Oct 2005 at 03:14 NZST, Florian Weimer wrote:
>
>> Is it true that there isn't yet a binding to SQLite versoin 3 from
>> Objective Caml?
>>
>> (I only found one for version 2.)
>
> There seem to be a couple of different ocaml-sqlite3 bindings around:
>
> http://www.imada.sd
The more I think about it, the proposed unified numeric model makes
a lot of sense and should be the default with no pragmas or compile-time
options for the old behavior. The dynamic manifest typing model of Sqlite
practically begs to have uniform mathematical results given the
dynamic nature o
Also, regarding the name change suggestions, I disagree.
As people have said, no database product is fully SQL standard
compliant, and SQLite is no different in that regard.
So in the current environment, SQLite's name is *not* misleading,
despite any deviations.
The name is a brand anyway,
To answer Richard's question directly:
I do not see the proposed change causing any hardship for me.
I happen to like static typing myself due to its ability to help
prevent bad data from propagating, with explicit variadic data type
for people that don't want to choose a more restrictive type
On 11/1/05, René Tegel <[EMAIL PROTECTED]> wrote:
> Jay Sprenkle wrote:
>
> >If you're going to become less compliant perhaps it would be less
> >misleading to remove the "SQL" from the project name. I'm not saying
> >either is a bad idea, just that the name shouldn't be misleading.
> >
> >
> I thi
I don't see any current integer behavior that cannot be emulated
with the new unified numeric type, but you might have to document
the behavior of mathematical operators under the new system.
Is modulus an integer operation or a floating point operation, for
example? Arguably, it could be eithe
I'd like to second Dennis' earlier remarks, and add some of my own.
One of my greatest hopes when I found SQLite (it's "value proposition")
was in having a great little database that would operate in such a
familiar way. By "familiar", I mean that it should execute the SQL
language, and produc
[EMAIL PROTECTED] wrote:
Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
All of the arguments against my proposed changes are
basically of the form that "this is not what the SQL standard
says". They are theoretical arguments based on a
Jay Sprenkle wrote:
If you're going to become less compliant perhaps it would be less
misleading to remove the "SQL" from the project name. I'm not saying
either is a bad idea, just that the name shouldn't be misleading.
I think this is kind of 'purist fetisjism'. Personally I like the
pragm
On Tue, Nov 01, 2005 at 01:45:04PM -0600, Jay Sprenkle wrote:
> > > I think it's a bit misleading to call the library "SQL-Lite: if
> > > you're going to redesign and not be like SQL. What do you think
> > > about creating a separate project for a fast light database
> > > engine that's not "SQL L
At 1:54 PM -0500 11/1/05, [EMAIL PROTECTED] wrote:
Please let me restate the proposed change: I desire to change
SQLite so that it no longer distinguishes between integer and
real. The two concepts are merged into a unified "numeric"
type.
And because all number values are of the same type,
> > I think it's a bit misleading to call the library "SQL-Lite: if you're
> > going to redesign
> > and not be like SQL. What do you think about creating a separate
> > project for a fast
> > light database engine that's not "SQL Like"?
>
> SQLite is very much SQL. It only deviates from the stand
- Original Message -
From: "Jay Sprenkle" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, November 01, 2005 2:08 PM
Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
> I think it's a bit misleading to call the library "SQL-Lite: if you're
> going to redesign
> and not be like SQL. What d
Jay Sprenkle said:
> On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> All of the arguments against my proposed changes are
>> basically of the form that "this is not what the SQL standard
>> says". They are theoretical arguments based on a world-view
>> that holds that strong-typing is
Jay Sprenkle <[EMAIL PROTECTED]> wrote:
> On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > All of the arguments against my proposed changes are
> > basically of the form that "this is not what the SQL standard
> > says". They are theoretical arguments based on a world-view
> > that hol
Well, since you put it that way. May I go one step farther and request
that this new Dynamic Type also adhere to "Bankers Rounding" commonly
implemented as BCD in other so equipped databases.
For years I have spent countless hours testing and sweating rounding
and comparisons using "Float" (Real
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> All of the arguments against my proposed changes are
> basically of the form that "this is not what the SQL standard
> says". They are theoretical arguments based on a world-view
> that holds that strong-typing is good and that it is the d
There is an ongoing debate on this subject at Lambda the Ultimate. One
approach that is sound is to introduce a new static type, called
DYNAMIC, that permits any value. Summarizing and seconding Dennis
Cote's suggestion, perhaps columns that have no type declared, or that
are declared DYNAMIC, beh
All of the arguments against my proposed changes are
basically of the form that "this is not what the SQL standard
says". They are theoretical arguments based on a world-view
that holds that strong-typing is good and that it is the duty
of database systems to enforce types.
I do not hold to that
Dennis Cote wrote:
The second issue is demonstrated by the last last three statements.
CREATE TABLE t (a REAL, b REAL);
INSERT INTO t VALUES (5, 2);
SELECT a / b FROM t;
Here he has explicitly declared the columns a and b to be of type
real. He then stores integer literal values into tho
Thank you for your insight into the state of SQLite "Typing." I think
this further exposes the need to establish our level of conformance to a
pretty much pervasive database standard (SQL.) I'm not certain that IBM
was the initiator of the term "Gray Area" but they certainly have
greatly increase
In Delphi we have the Type: "Variant," which is pretty much "Type-less"
for OOP purposes.
> -Original Message-
> From: Doug Currie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 01, 2005 11:25 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Tuesday, November 1, 2005, 11:53:11 AM, [EMAIL PROTECTED] wrote:
> Static typing in SQL is designed not to help the users of SQL
> databases, but rather to help the implementors of SQL database
> engines.
There are uses for static typing. Types in the SQL context can be used
as a kind of integrit
"Anton Kuznetsov" <[EMAIL PROTECTED]> wrote:
> Hello!
>
> Did anybody try to create an SQLite3 database with a custom page_size (e.g.
> 8192) and fill it with data of more than 1Gb? As for me I didn't
> manage (using tclsqlite-3.2.7). It says "database disk image is malformed".
>
I just testing
Joe Wilson <[EMAIL PROTECTED]> wrote:
> I've found a potential problem -
> round() is not a good substitute for the old integer truncation.
>
> Consider the previous Sqlite3 behavior:
>
> sqlite> select 15/8;
> 1
> sqlite> select round(15.0/8.0);
> 2
>
> Can you recommend or provide a n
"Fred Williams" <[EMAIL PROTECTED]> wrote:
> Ah the sticky wicket that is "Type less" :-) We now have issues
> evolving as a direct result of that feature in our cute little database.
> We now seem to have by backing into it: Really Restricted Integer, Real,
> DateTime (sort of), and Text. BLOB a
Preston Zaugg wrote:
I would NOT be in favor of this change. As was discussed in the
original post this would be NON-STANDARD behavior. The SQL-99 spec
says that integer math remains an integer.
The only time I would like an integer to return a "real" result is if
that integer is stored in
Hello!
Did anybody try to create an SQLite3 database with a custom page_size (e.g.
8192) and fill it with data of more than 1Gb? As for me I didn't
manage (using tclsqlite-3.2.7). It says "database disk image is malformed".
Thanks.
Anton.
I've found a potential problem -
round() is not a good substitute for the old integer truncation.
Consider the previous Sqlite3 behavior:
sqlite> select 15/8;
1
sqlite> select round(15.0/8.0);
2
Can you recommend or provide a new function that performs correct integer
trunction?
--- [
On Tue, 1 Nov 2005, Gerry Snyder wrote:
>Allan, Mark wrote:
>>
>>
>> We do believe however that journaling the database for us
>> is of no benefit as our filing system is 100% fail safe and will
>> return to the last flushed state of the file on power loss.
>
>Mark,
>
>I am probably in over m
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I am proposing to make the changes outlined below in SQLite
> version 3.3.0 and I am wondering if these changes will cause
> any severe hardship.
Stay with the SQL standard, if that's not clear follow what other languages do..
int operato
Ah the sticky wicket that is "Type less" :-) We now have issues
evolving as a direct result of that feature in our cute little database.
We now seem to have by backing into it: Really Restricted Integer, Real,
DateTime (sort of), and Text. BLOB and CLOB away at your own risk!
Is it time to offic
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> How do intend to treat 5/2 if passed to an Sqlite function expecting
> an integer argument?
Exactly the same thing that happens now if you pass 2.5
into that same function: it truncates the value to an
integer 2.
--
D. Richard Hipp <[EMAIL PROTECTED]>
"Preston Zaugg" <[EMAIL PROTECTED]> wrote:
> As was discussed in the original
> post this would be NON-STANDARD behavior.
> The SQL-99 spec says that integer
> math remains an integer.
>
The change I propose (and have now checked into CVS, btw,
though I might still back it out) does not violat
Gerry,
We are using a flash filesystem.
The changes are made to a separate area of the flash, when the file is flushed
then the descriptor blocks are updated to point to the new block of flash. If
the power is lost before the file is flushed then the descriptor is not updated
and therefore the
What happened to the old: Integer arithmetic produces integer results
rule? I thought that was either a "Standard" or at least a very old
artifact. Is it not how most Language math functions work?
I like the Pragma idea on this one.
> -Original Message-
> From: Joe Wilson [mailto:[EMAI
For what it is worth
I would NOT be in favor of this change. As was discussed in the original
post this would be NON-STANDARD behavior. The SQL-99 spec says that integer
math remains an integer.
The only time I would like an integer to return a "real" result is if that
integer is stored in
Although all my Sqlite3 databases depend on integer division truncation
and would break with your proposed change I agree that 5/2 should equal
2.5 in order to be more consistant with other databases. I can migrate
my databases to use round(). But might it be possible to create a
backwards compa
Allan, Mark wrote:
We do believe however that journaling the database for us
is of no benefit as our filing system is 100% fail safe and will
return to the last flushed state of the file on power loss.
Mark,
I am probably in over my head, as usual, but how do you recover if power
go
I am proposing to make the changes outlined below in SQLite
version 3.3.0 and I am wondering if these changes will cause
any severe hardship.
Two changes working together:
(1) Floating point values are *always* converted into
integers if it is possible to do so without loss
of info
Thanks for your detailed reply. Would you mind answering my follow up queries?
> The ability to disable journaling is not a supported behaviour of
> SQLite. If you can get it to work, that's great. But if not, that
> is not considered a bug.
Ok so the ability to not be able to disable journalin
"Allan, Mark" <[EMAIL PROTECTED]> wrote:
> I definately have a problem when I disable journalling on version 3.2.7
> of SQLite. I dont see the same problem with 3.2.1 of SQlite.
> I disable the journalling of the database file as described in my
> earlier email.
> With version 3.2.7 this causes S
I definately have a problem when I disable journalling on version 3.2.7 of
SQLite. I dont see the same problem with 3.2.1 of SQlite.
I disable the journalling of the database file as described in my earlier email.
With version 3.2.7 this causes SQlite to not sync the database file after some
upd
Hannes Ricklefs wrote:
>
> Hi,
>
> does anyone know what error code 25 stands for I can't find it in the
> documentation! It occurs in relation to binding values to a prepared
> statement.
>
> THanks,
> Hannes
You can find all codes in the sqlite.h include file:
#define SQLITE_RANGE 25
Hi,
does anyone know what error code 25 stands for I can't find it in the
documentation! It occurs in relation to binding values to a prepared
statement.
THanks,
Hannes
Can anybody tell me if I will suffer any sideaffects if I disable the
journalling of the database file with version 3.2.7?
We have changed the SQlite code locally to omit the journalling of the database
file by supplying 1 as the value for omitJournal to calls to the function
sqlite3BtreeFacto
57 matches
Mail list logo
