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

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

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-11 Thread Greg Obleshchuk
and 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

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

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
PROTECTED] Sent: Wednesday, April 07, 2004 11:22 PM 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 Feedback from the user community is strongly encouraged. An executive summary

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
PROTECTED] Sent: Wednesday, April 07, 2004 11:22 PM 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 Feedback from the user community is strongly encouraged. An executive summary

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

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

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: >

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

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

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*

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 S

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread basil . thomas
ssage- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 9:22 AM To: [EMAIL PROTECTED] 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 Feedback from the user commun

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Jakub Adamek
? Thanks for your excellent work, Jakub Adamek 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

RE: [sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite version 3.0

2004-04-08 Thread Steve O'Hara
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 08 April 2004 04:05 To: [EMAIL PROTECTED] Subject: [sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite version 3.0 Jeff, Jeff Pleimling <[EMAIL PROTECTED]> 08/04/2004 12:42 PM To: [EMAIL PROTECTED]

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.

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

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Fred Williams
mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 9:09 PM > To: [EMAIL PROTECTED] > Subject: [sqlite] A proposal for SQLite version 3.0 > > > Vote for a database parameter:IS

[sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread ben . carlyle
Jeff, Jeff Pleimling <[EMAIL PROTECTED]> 08/04/2004 12:42 PM To: [EMAIL PROTECTED] cc: Subject: Re: [sqlite] A proposal for SQLite version 3.0 At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote: > I believe you're thinking of a 'cluste

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

[sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Tom Shafer
Vote for a database parameter:IS NULL A VALUE ? YES or NO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

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

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

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

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

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

2004-04-07 Thread Mateusz Łoskot
In 04/08/2004 05:38 AM, Roy Black wrote: I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. How is it possible ? My opinion is closer (but not exact) to Jakub's. I have 3 databases, each database has the same structure (about 100 tables) but different amount

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Simon Berthiaume
How would this change in 3.0? > > Thanks for your excellent work, > > Jakub Adamek > > D. Richard Hipp wrote: > > > A design proposal for SQLite version 3.0 can be found at: > > > > http://www.sqlite.org/prop2.html > > > > Feedback

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Steve O'Hara
PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]&

RE: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Allan Edwards
To: [EMAIL PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROT

Fw: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Roy Black
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 storage efficient in the common case. In a typical table, S

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

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: > >* Su

Re: [sqlite] A proposal for SQLite version 3.0

2004-04-07 Thread Jakub Adamek
roughly about 3x bigger files than MS Access. How would this change in 3.0? Thanks for your excellent work, Jakub Adamek 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

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