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
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
.
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: [sqlite] A proposal
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
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
=== 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 SQL statement.
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
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
> 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
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
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
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
>
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 not
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
gt;
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 stor
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?
>
SQLi
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:
>
>* Support for UTF-16
>
>I do
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
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
30 matches
Mail list logo
