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
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
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
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
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
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
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
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
=== 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
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
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:
>
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
> >
> > 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
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*
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
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
?
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
: [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]
> 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.
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
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
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
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
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]
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
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
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
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
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
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
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]&
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
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
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
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
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
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
37 matches
Mail list logo
