RE: [sqlite] A proposal for SQLite version 3.0

2004-04-20 Thread Mikhail Fedotov
Hi! >SQLite is very storage efficient in the common case. In a typical table, SQLite will use >about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another >way, about 60% to 75% of an SQLite database file is the actual data being stored >and the other 40% to 25% is overh

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-12 Thread Mark D. Anderson
Echoing some others' responses, particularly Darren's: 1. I don't see the rationale for putting much priority on multiple string encodings. After all, blobs still can't be stored natively :). UTF-16 adds extra complexity, because of embedded nulls, and because of its own need for a byte-order-ma

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread D. Richard Hipp
Greg Obleshchuk wrote: > > The data types I think are great but can we have a large and small integer? > I noticed some people (embedded systems people) complain about this. Version 3.0 will use 1, 2, 4, or 8 bytes to store an integer, depending on how big the number is. It uses the fewest number

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Greg Obleshchuk
it would collate using the open parameter by default. If there was a column override then it would use that Greg - Original Message - From: Darren Duncan To: [EMAIL PROTECTED] Sent: Monday, April 12, 2004 8:46 AM Subject: RE: [sqlite] A proposal for SQLite version 3.0 At

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Darren Duncan
At 11:22 PM +0100 4/11/04, Steve O'Hara wrote: I agree with Greg, the most irksome feature of SQLite is the case sensititvity - it's one of the few things MS got right with SQLserver. I know this is more mainstream/standard SQL behaviour but it's outdated in modern SQL applications that nearly alw

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Darren Duncan
At 11:22 PM +0100 4/11/04, Steve O'Hara wrote: I agree with Greg, the most irksome feature of SQLite is the case sensititvity - it's one of the few things MS got right with SQLserver. I know this is more mainstream/standard SQL behaviour but it's outdated in modern SQL applications that nearly alw

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Greg Obleshchuk
Hi Will, Thanks for clearing that up for me, it make more sense now. Greg - Original Message - From: Will Leshner To: Forum SQLite Sent: Monday, April 12, 2004 8:06 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Steve O'Hara
rching. In fact, I'd go one step further and advocate making SQLite case-insensitive as a rule. I'm waiting for the flames... Steve -Original Message- From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] Sent: 11 April 2004 23:02 To: D. Richard Hipp; [EMAIL PROTECTED] Subject: Re:

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Will Leshner
On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk wrote: You state that there may or may not be the call-back function wrapper. I would be an advocate for keeping it. This way of handling returned data is most useful. Sometimes when returning thousands or more rows of data you want to cancel the

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Greg Obleshchuk
Hello, I just read the proposed changes and they seem fine. A couple of thing. The data types I think are great but can we have a large and small integer? I noticed some people (embedded systems people) complain about this. I quite happy with the large type but as integers will now be store

Re: Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread Nuno Lucas
=== On 2004-04-09, D. Richard Hipp wrote === .. > >The reason for not doing this is that maintenance of the counter >slows down inserts and deletes. Is having a constant-time count(*) >really work slower inserts and deletes? If you have opinions on >this, speak up now, because it won't be an opti

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread Andrew Carter
Windows UTF-16 is represented by WCHAR. It is always 2 bytes. UCS-2 can be 3 or more bytes but these are for extended characters outside the ones used for real language. For example, musical notation symbols use the third byte. I don't think any OS's use UCS2 directly. I know Oracle supports U

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread Andrew Carter
I'm assuming UTF-8 support will still be there as well? For Windows applications, UTF-16 is much more prevalent. -- Andrew On Wed, 7 Apr 2004, Christian Smith wrote: > On Wed, 7 Apr 2004, D. Richard Hipp wrote: > > >A design proposal for SQLite version 3.0 can be found at: > > > > http://w

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread Doug Currie
Friday, April 9, 2004, 6:54:44 AM, D. Richard Hipp wrote: > Nuno Lucas wrote: > > I have a feature that would be nice in a 2.8.x version, but I can live with > > it if only on 3.0. It's the optimization for the many times used "SELECT > > COUNT(*) FROM ...", at least if FROM is a table or a vi

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread D. Richard Hipp
Nuno Lucas wrote: > I have a feature that would be nice in a 2.8.x version, but I can live with > it if only on 3.0. It's the optimization for the many times used "SELECT > COUNT(*) FROM ...", at least if FROM is a table or a view. > > I don't know exactly why it takes so much time, but if a file f

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-09 Thread Nuno Lucas
Hi, I passed my eyes over the proposal and all seems ok to me (haven't made a through read yet, but I have total confidence on the good work of D. Richard Hipp). I have a feature that would be nice in a 2.8.x version, but I can live with it if only on 3.0. It's the optimization for the many times

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Dennis Cote
D. Richard Hipp wrote: > The 1st and 3rd APIs above will work, but not the second. Remember, > SQLite 3.0 will have manifest typing, which means that type of the > data can change from one row to the next. Type is not associated > with a column, as in standard SQL. So there is no way to know the

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Tim McDaniel
> > > > A statement's parameter values would be reset to null > values when the > > statement is reset. > > > > Is that really the desired behavior? If you want to reset > parameters on a statement reset, wouldn't it be better to do > so explicitly. That way, if a statement has 10 paramete

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread D. Richard Hipp
Dennis Cote wrote: The API should provide functions that allow the application to inspect the number, type, and names of the parameters that were discovered while parsing the SQL. These functions could be called any time after the statement is prepared. int sqlite3_param_count(sqlite3_stmt* stm

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Darren Duncan
On Thu, 8 Apr 2004, Dennis Cote wrote: > I would like to propose some additions to the API to support named > parameters in the SQL statement. These features will make it easier to use Well explained, Dennis. I had also given a paragraph in support for named parameters, but you explained the ma

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Dennis Cote
D. Richard Hipp wrote: > A design proposal for SQLite version 3.0 can be found at: > > http://www.sqlite.org/prop2.html > Richard, I read your proposal and it all look very promising to me. I would like to propose some additions to the API to support named parameters in the SQL statement. T

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread basil . thomas
The proposal for version 3.0 looks very promising and I hope all the major changes will be implemented. Most of the enhancements seem to add flexibility and scalability to to the "C" based api. This is great as at the "C" api call level you can do anything you want. But I do not see any changes to

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Jakub Adamek
Yes, that is right, my database consists of mainly numbers. Some of them have 10 digits, some have less. This would explain part of the difference. I was also wondering if Access perhaps has some type of index comprimation, like cutting pre- and postfixes in the B-tree. Jakub Simon Berthiaume

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Paul L Daniels
> Could we please see the current behaviour set in stone? I'd like to know > that generated keys will always fit into 32 bits (provided I don't > exceed ~4.3 billion records, naturally). I think that it's a dangerous precent to fix these things in stone, certainly at the source level. Perhaps

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Andrew Francis
I have an application which depends on INTEGER PRIMARY KEY values fitting into 32 bits. I know that currently, the keys are generated with MAX()+1, but this behaviour is "undocumented and liable to change.: Now that rowid's are going 64 bit, a truly random INTEGER PRIMARY KEY may not fit into 3

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread bnason
I would like to request that pages be exactly a power of 2 size (including headers), and that when reading and writing pages the buffers are aligned to a reasonably large power of 2 size. The reason for this is that often in embedded systems the low level device drivers and filesystems work *much*

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Fred Williams
Null is not a value. The definition of NULL is that a value has not been assigned and is therefore unknown. Once a value is assigned, Null is no longer valid. Unless somebody changed the definition in the last thirty years or so :-) > -Original Message- > From: Tom Shafer [mailto:[EMAIL

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Jeff Pleimling
At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote: A little while ago a list reader suggested a kind of index (from ms access, if I recall... I don't recall the term they used) that is not external. Instead the index changes the order in which the table itself is organised. I believe you're think

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread ben . carlyle
Peoples :) "D. Richard Hipp" <[EMAIL PROTECTED]> 07/04/2004 11:22 PM To: [EMAIL PROTECTED] cc: Subject:[sqlite] A proposal for SQLite version 3.0 > A design proposal for SQLite version 3.0 can be found at: > http://www.sqlite.org/prop2.html > Feed

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread D. Richard Hipp
Darren Duncan wrote: Here are some of the things I like (correct me if any actually not present): Your summary looks very good. Thanks you. - SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE. - Actual blobs c

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread D. Richard Hipp
eno wrote: well, the question is: Support UTF-16 to what extent? I think here of sorting questions, (but other may arise). Obviously, sorting within a single language is specific to that language, whereas sorting a, say, german word with an ukrainian word is what a programmer calls "undefined".

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread eno
D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 well, the question is: Support UTF-16 to w

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Darren Duncan
At 9:22 AM -0400 4/7/04, D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. Hey, this looks great! Here are some of the things I like (correct me if any actually not pres

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Brett Granger
D. Richard Hipp wrote: Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Simon Berthiaume
It might be true if you mostly store large quantities of NUMERICAL data (float, int, ...) since they are currently stored as strings (the value 1234567, would be stored using at least 7-8 bytes instead of 4). If you were in the same situation as I, where I use database mostly for strings, you would

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread James W. Walker
"D. Richard Hipp" <[EMAIL PROTECTED]> wrote: So what datatype are most systems expecting to use for UTF-16 strings? Who can provide me with a list? Or even a few examples? Here's one: On Mac OS X, a UTF-16 string would typically be UniChar*, where UniChar is a typedef for unsigned short, with a

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Steve O'Hara
TED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Allan Edwards
ECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is v

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread D. Richard Hipp
Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread D. Richard Hipp
Simon Berthiaume wrote: >> Notice that text strings are always transferred as type "char*" even if the text representation is UTF-16. This might force users to explicitely type cast some calls to function to avoir warnings. I would prefer UNICODE neutral functions that can take either one of t

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Christian Smith
On Wed, 7 Apr 2004, D. Richard Hipp wrote: >A design proposal for SQLite version 3.0 can be found at: > > http://www.sqlite.org/prop2.html > >Feedback from the user community is strongly encouraged. >An executive summary of the proposed changes follows: > >* Support for UTF-16 > >I do not

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Jakub Adamek
Hello, I am using SQLite in a car navigation system which should work on PDAs as well. Thus speed and size is crucial for us. SQLite is superb in the speed category, but the size of its file is not so superb. I see you mentioned something about file size. My experience is that SQLite makes rou

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread aducom
As a developer of Delphi components for SQLite I would recommend a new function for both releases to investigate the fileversion. Perhaps it's already there. Of course you can open a database and wait for an exception to occur, but this is not a very clean way of doing things. Having this possi