[sqlite] Can this be done in SQLite?

[K. P.]

Brilliant - thanks.Though I still do not understand my errordistinct(t.LastName 
|| ', ' || t.FirstName),Seems to me that I am passing a single argument in 
parentheses to distinct

> To: sqlite-users at mailinglists.sqlite.org
> From: rsmith at rsweb.co.za
> Date: Fri, 9 Oct 2015 00:38:10 +0200
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> 
> On 2015-10-09 12:22 AM, K. P. wrote:
> > I tried this, of course, before asking, but:
> > group_concat(distinct(t.LastName || ', ' || t.FirstName), '; ') As Teachers,
> > gives
> > [15:19:32] Error while executing SQL query on database 'test': DISTINCT 
> > aggregates must have exactly one argument
> 
> As the error suggests, it can't have more than one argument (parameter), 
> so this should work:
> 
> group_concat(distinct (t.LastName || ', ' || t.FirstName || '; ')) As 
> Teachers,
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Can this be done in SQLite?

[Simon Slavin]

On 8 Oct 2015, at 10:47pm, K. P.  wrote:

> Am using SQLiteStudio - which I really like - though I have wondered if it 
> passes all its knowledge around errors onto the user...

For such experimentation I recommend the SQLite command line tool.  It's the 
thinnest practical shell around the raw SQLite API, and written by the SQLite 
developer team.  If it produces an error you're 100% sure that this is the 
error generated by the API.

GUI tools like SQLiteStudio are fine ... for routine or simple organisations 
that you understand.  I just wouldn't use it for learning something new.

Simon.

[sqlite] Can this be done in SQLite?

[Simon Slavin]

On 8 Oct 2015, at 9:54pm, K. P.  wrote:

> Thanks for that.I'd need something along the lines of
> 
> group_concat(c.LastName || ', ' || c.FirstName, ';') as ClientName, 
> 
> 
> which in itself does not seem to be supported.

Why not ?  What is the complete SELECT command ?  What happens when you try it ?

If it really isn't valid ...

Create a VIEW which returns the individual concatenations.  Then use 
group_concat() in a SELECT on the VIEW.

Simon.

[sqlite] Can this be done in SQLite?

[K. P.]

I tried this, of course, before asking, but:
group_concat(distinct(t.LastName || ', ' || t.FirstName), '; ') As Teachers, 
gives
[15:19:32] Error while executing SQL query on database 'test': DISTINCT 
aggregates must have exactly one argument

> To: sqlite-users at mailinglists.sqlite.org
> From: rsmith at rsweb.co.za
> Date: Thu, 8 Oct 2015 23:58:09 +0200
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> 
> On 2015-10-08 11:47 PM, K. P. wrote:
> > Am using SQLiteStudio - which I really like - though I have wondered if it 
> > passes all its knowledge around errors onto the user...
> 
> I hope it does. Try some other ones too, just to get a wider idea. 
> Perhaps http://www.sqlc.rifin.co.za/ or http://www.sqliteexpert.com/ if 
> on Windows, or https://github.com/sqlitebrowser/sqlitebrowser if on 
> Linux/Mac.  If any of them do things that seem odd, and you are 
> comfortable using command line tools, the sqlite3 CLI is best for 
> checking/testing SQL at http://www.sqlite.org/download.html
> 
> As to your distinct question, sure, use like this:
> 
> SELECT group_concat(DISTINCT fullName) FROM sometable WHERE 1;
> 
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] version 3.9.0 doc errors

[R.Smith]

*** Correction ***

On 2015-10-08 10:03 PM, R.Smith wrote:
>
> To clarify, when used as an adverb to modify a verb, you may well add 
> the s - such as saying "I'm moving backwards" or "It's a forwards 
> marching army."//...

"Marching" is of course an adverb here, not a verb. A more correct 
example would be: "He's forwards marching".

[sqlite] version 3.9.0 doc errors

[R.Smith]

On 2015-10-08 08:58 PM, Donald Griggs wrote:
> Regarding:
>2nd paragraph - The New Version Numbering System (auxiliary letter):
> "The second number Y is incremented for any change that breaks forward*s*
> compatibility..."
>
> Not that it matters much, but in general it seems that adding the "s" to
> backward and forward is more often done in British English vs American.
>
> Also, backward is said to be more used for the adjective and backwardS when
> used as an adverb.
 :)

Yes, you're quite right. Sometimes though, these quick web references 
don't tell the whole story, but she isn't wrong.

In the case at hand, it is A - American English we're trying to do, and 
B - Though forward here is an adverb, it is really used as a modifier to 
an adjective (Compatible) which is slightly different to when used as a 
modifier to a verb (which is the normal sense in which they mean "when 
used as an adverb" as per the link).

To clarify, when used as an adverb to modify a verb, you may well add 
the s - such as saying "I'm moving backwards" or "It's a forwards 
marching army."  Sometimes adding the s just feels wrong, even in UK 
English, such as saying "She is a forward thinking person" or "He played 
a brilliant forward stroke" - adding an s will be weird here.

When it modifies an adjective, while it still technically is an adverb, 
it is mostly used sans the s - try to say these out loud (with and 
without the trailing s): "backward hand signal", "forward compatible 
device" etc. It may alter the meaning or should "feel" uncomfortable to 
say when you add the s (I hope!).

When used as a modifier to another adverb, anything goes, mostly in 
America without the s and in UK with the s. Such as: "backward(s) 
slanted letters", "forward(s) facing lights", "backward(s) running 
clock" etc.

[sqlite] Can this be done in SQLite?

[K. P.]

Almost there - just one issue left:
I now receive a list of students per class - perfect.
I also do a group_concat on the teachers (as a class could be taught by more 
than one) and so I I get the same teacher repeated a number of times at times.
Any way I can apply a 'distinct' here?

> To: sqlite-users at mailinglists.sqlite.org
> From: rsmith at rsweb.co.za
> Date: Thu, 8 Oct 2015 23:34:05 +0200
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> 
> On 2015-10-08 11:30 PM, K. P. wrote:
> > It does indeed work - had to make myself a simpler query than the real life 
> > one to see this. I probably had some other syntax error that I mistook for 
> > it...
> > Thanks!
> 
> Nice.
> Are you logging the SQLite errors and error descriptions? It's usually 
> quite good at explaining where exactly your query goes wrong.
> 
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Can this be done in SQLite?

[K. P.]

Am using SQLiteStudio - which I really like - though I have wondered if it 
passes all its knowledge around errors onto the user...

> To: sqlite-users at mailinglists.sqlite.org
> From: rsmith at rsweb.co.za
> Date: Thu, 8 Oct 2015 23:34:05 +0200
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> 
> On 2015-10-08 11:30 PM, K. P. wrote:
> > It does indeed work - had to make myself a simpler query than the real life 
> > one to see this. I probably had some other syntax error that I mistook for 
> > it...
> > Thanks!
> 
> Nice.
> Are you logging the SQLite errors and error descriptions? It's usually 
> quite good at explaining where exactly your query goes wrong.
> 
> 
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Can this be done in SQLite?

[K. P.]

It does indeed work - had to make myself a simpler query than the real life one 
to see this. I probably had some other syntax error that I mistook for it...
Thanks!

> To: sqlite-users at mailinglists.sqlite.org
> From: rsmith at rsweb.co.za
> Date: Thu, 8 Oct 2015 23:19:53 +0200
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> 
> On 2015-10-08 10:54 PM, K. P. wrote:
> > Thanks for that.I'd need something along the lines of
> >
> > group_concat(c.LastName || ', ' || c.FirstName, ';') as ClientName,
> >
> >
> > which in itself does not seem to be supported.
> 
> This would be quite a normal group concatenation and works perfectly well...
> 
> Why do you believe it doesn't work or isn't supported?
> 
> 
> > c.LastName || ', ' || c.FirstName, ';') as FullName,
> > group_concat(FullName, ';') as ClientName,
> 
> Ok, this won't work, but not for the reasons you think. An alias cannot 
> be referenced in the same select header as it is instantiated. You can 
> however achieve this with a CTE (among other ways), something like this 
> (I made up A and B here cause I don't know the rest of your schema):
> 
> WITH cte1(A, B, FullName) AS (
>SELECT c.A, c.B, c.LastName || ' ' || c.FirstName FROM someTable AS 
> cWHERE 1
> )
> SELECT A, B, group_concat(FullName, '; ')
> FROM cte1
>   WHERE 1
>   GROUP BY A, B
>   ORDER BY A, B
> 
> Perhaps you don't wish to have names repeated, in which case this will 
> work better:
> 
> WITH cte1(A, B, FullName) AS (
>SELECT c.A, c.B, c.LastName || ' ' || c.FirstName FROM someTable AS 
> cWHERE 1
> )
> SELECT A, B, group_concat(DISTINCT FullName)
> FROM cte1
>   WHERE 1
>   GROUP BY A, B
>   ORDER BY A, B
> 
> 
> 
> If you have some SQL that doesn't seem to work, kindly post your table 
> schema and the full SQL you are trying to do, that way we can form a 
> better idea of what you aim to do and provide more complete answers.
> 
> Cheers!
> Ryan
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

On 10/8/15, Darren Duncan  wrote:
>
> 2.  If two successive versions have an overlapping but not equal API and
> file format, meaning that a subset of data files but not all of such readable 
> or
> writeable by one version is readable and writeable by the other, or that a
> subset of code but not all of such that is correctly working against one
> version is likewise against the other, then the X at least should be 
> different.
> This mainly is for releases that add or remove or change features.
>

SQLite has the additional restriction that it does not break legacy.
It only adds new features.  Otherwise, this seems to be a reasonable
description of what I am trying to achieve.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] Can this be done in SQLite?

[K. P.]

Thanks for that.I'd need something along the lines of

group_concat(c.LastName || ', ' || c.FirstName, ';') as ClientName, 


which in itself does not seem to be supported.


c.LastName || ', ' || c.FirstName, ';') as FullName, 
group_concat(FullName, ';') as ClientName, 


also not :(


Any way around this?





> From: slavins at bigfraud.org
> Date: Thu, 8 Oct 2015 17:01:06 +0100
> To: sqlite-users at mailinglists.sqlite.org
> Subject: Re: [sqlite] Can this be done in SQLite?
> 
> 
> On 8 Oct 2015, at 4:59pm, K. P.  wrote:
> 
> > Given the following tables, is it possible to extract rows of class data 
> > along with all participating student names concatenated in one column in a 
> > single SQL query?
> 
> See the 'group_concat()' function:
> 
> 
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] version 3.9.0 doc errors

[R.Smith]

More draft doc errors:
https://www.sqlite.org/draft/versionnumbers.html

1st paragraph - SQLite Version Numbers (typo for "through"):
"There are two strategies for version numbers in SQLite. The historical 
system, in use from the first release on 2000-08-17 *though* version 
3.8.11.1 on..."

---

2nd paragraph - The New Version Numbering System (auxiliary letter):
"The second number Y is incremented for any change that breaks 
forward*s* compatibility..."

---

In https://www.sqlite.org/draft/releaselog/3_9_0.html
New features and enhancements (grammar typo):
"Enhance the dbstat virtual table so that it can be used as a 
table-valued functions where..."

I think it meant to read like this:
"Enhance*d* the dbstat virtual table so that it can be used as a 
table-valued *function* where..."

---


Cheers,
Ryan

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[R.Smith]

On 2015-10-08 06:21 PM, Richard Hipp wrote:
> It all really boils down to this:  What is the difference between a
> "major" and a "minor" change?
>

Agreed, and the decision between whether an item is major or minor is 
always going to be a blurred line.  It is not important for the issue at 
hand either, the decision on reshaping the scheme simply has to cater 
for how to present the version once a major or minor change is 
registered. The guidelines on how to decide whether a change is "major" 
or "minor" is an important but different conversation, and probably 
already rather well-defined (or at least: mostly agreed upon).

I think the scheme proposed is great and will fit most general cases - 
no doubt somebody somewhere will have a need at a tangent, but the 
proposed definitely services the questions and ideals to date.

Also, thank you kindly for the efforts toward this.

+1 for the new scheme.
Ryan

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Darren Duncan]

On 2015-10-08 6:03 PM, Richard Hipp wrote:
> On 10/8/15, Darren Duncan  wrote:
>>
>> 2.  If two successive versions have an overlapping but not equal API and
>> file format, meaning that a subset of data files but not all of such 
>> readable or
>> writeable by one version is readable and writeable by the other, or that a
>> subset of code but not all of such that is correctly working against one
>> version is likewise against the other, then the X at least should be 
>> different.
>> This mainly is for releases that add or remove or change features.
>
> SQLite has the additional restriction that it does not break legacy.
> It only adds new features.  Otherwise, this seems to be a reasonable
> description of what I am trying to achieve.

Thank you.

In that case, I could generalize and simplify my proposal as follows...

I would propose that with a W.X.Y semantic version scheme, the parts mean 
essentially [breaks-backward.breaks-forward.breaks-nothing], by which I mean:

1.  If a newer version is incapable of doing something correctly that an older 
version is capable of doing correctly, such as supporting a particular API call 
with same behavior or such as reading or writing a particular file format, then 
the newer version should have a greater W than the older one.  This is for when 
a backwards-compatibility break occurs such as because a feature was removed. 
The key point is a user can not simply take any code or file that works with 
the 
prior version and expect it to work without changes with the newer version.

2.  Otherwise, if a newer version is capable of doing something correctly that 
an older version is incapable of doing correctly, such as supporting a 
particular API call with same behavior or such as reading or writing a 
particular file format, then the newer version should have a greater X than the 
older one.  This is for when a forwards-compatibility break occurs such as 
because a feature was added.  The key point is a user can not simply take any 
code or file that works with the newer version and expect it to work without 
changes with the prior version.

3.  Otherwise, there are no known compatibility breaks, and the newer version 
only needs to have a greater Y than the older one.  Users are free to move in 
both directions as long as any fixed (or created) bugs don't affect them.

Note that while a backwards-compatibility break may happen in the same version 
as a forwards-compatibility break, such as a feature or API or file format 
substitution, this doesn't necessarily have to be the case; adding the new and 
removing the old could be done in separate versions.

As an exception to the above definitions, when W is zero, then X is incremented 
for both backward-breaking and forward-breaking changes (while Y keeps its 
meaning); once W is greater than zero, that stops being the case.

As with before, incrementing a number has no implication on the size of the 
change, just on how it is treated.  For example, a large code refactoring that 
just affects performance but is non-breaking can still be a Y change.

As with before, one can optionally increment a number position without being 
required to, such as for marketing reasons or to mark a maintenance branch.

Note that the main break from my prior proposal is that incrementing W no 
longer 
needs to mean independent product or disjoint API etc, though that is allowed; 
if one wants a position to explicitly mean that only, then I would advocate 
having an extra digit, where a new leaving one, V, means disjoint, and the 
others have the meanings I said above.  But given SQLite's goals, W may never 
increase anyway for decades, so we can save on that redundancy.

-- Darren Duncan

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Darren Duncan]

Richard, I agree with your proposal herein stated, at least as I understand it.

I would propose that with a W.X.Y semantic version scheme, which I think is 
what 
you said, the parts mean essentially [disjoint.overlapping.equal], by which I 
mean:

1.  If two successive versions have a disjoint API and file format, meaning 
separate namespaces as if they were unrelated projects, and they can't read or 
write each others' files, then the W at least should be different.  You do this 
between SQLite 2 and 3.

2.  If two successive versions have an overlapping but not equal API and file 
format, meaning that a subset of data files but not all of such readable or 
writeable by one version is readable and writeable by the other, or that a 
subset of code but not all of such that is correctly working against one 
version 
is likewise against the other, then the X at least should be different.  This 
mainly is for releases that add or remove or change features.

3.  If two successive versions have an equal API and file format, meaning that 
all files readable and writeable by one version are likewise by the other, and 
all code that works correctly with one version's API does so with the other, 
then the Y at least should be different.  This mainly is for releases that just 
help performance or fix bugs.

4.  Optionally a 4th part Z can be used to indicate maturity such as whether it 
is a pre-production (including RC) release or production, or be used by third 
party packagers for packaging version etc.

Note that my above definition generally is invariant to the arrow of time, so 
users can either upgrade or downgrade versions using the same rules with the 
same expectation of compatibility.  That is, the concept of 
forwards-compatibility and backwards-compatibility are effectively treated the 
same.  The only exception regards fixing bugs, as that is a case where 
something 
that works with one version wouldn't work with the other, but in that case no 
one should be purposefully moving to a buggier version.  Of course, newer 
versions should still always have higher numbers in the position incremented 
than their prior ones, I'm not suggesting otherwise.

Note that optionally one can increment a higher-valued position when they 
otherwise don't need to based on compatibility, such as for reasons of wanting 
to define a parallel maintenance branch, or such as for marketing reasons.

Richard, does that still seem to describe your intentions?

-- Darren Duncan

On 2015-10-08 6:38 AM, Richard Hipp wrote:
> Several users have proposed that SQLite adopt a new version numbering
> scheme.  The proposed change is currently uploaded on the "draft"
> website:
>
>  https://www.sqlite.org/draft/versionnumbers.html
>  https://www.sqlite.org/draft/releaselog/3_9_0.html
>  https://www.sqlite.org/draft/
>
> If accepted, the new policy will cause the next release to be 3.9.0
> instead of 3.8.12.  And the second number in the version will be
> increased much more aggressively in future releases.
>
> Your feedback on the proposed policy change is appreciated.  We will
> delay the next release until there is a semblance of consensus on the
> new policy.
>

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Jaroslaw Staniek]

On 8 October 2015 at 15:38, Richard Hipp  wrote:

> Several users have proposed that SQLite adopt a new version numbering
> scheme.  The proposed change is currently uploaded on the "draft"
> website:
>
> https://www.sqlite.org/draft/versionnumbers.html
> https://www.sqlite.org/draft/releaselog/3_9_0.html
> https://www.sqlite.org/draft/
>
> If accepted, the new policy will cause the next release to be 3.9.0
> instead of 3.8.12.  And the second number in the version will be
> increased much more aggressively in future releases.
>
> Your feedback on the proposed policy change is appreciated.  We will
> delay the next release until there is a semblance of consensus on the
> new policy.
>

?Thanks, looks solid for me.

PS: For cmake users I am committing myself to update the FindSqlite.cmake
detection script in areas where it's needed.
Even for the current versioning approach I introduced
SQLITE_MIN_VERSION_PATCH variable among others.[1] Its semantics can be
easily made compatible with the proposed new versioning approach by making
the variable optional. I welcome any further suggestions, also contributing
the file to cmake itself since SQLite is so popular.

[1]
https://phabricator.kde.org/diffusion/KDB/browse/master/cmake/modules/FindSqlite.cmake

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

[sqlite] Problem with sqlite3_db_filename

[Bart Smissaert]

Ignore this as I know what the problem was.
I was passing a pointer to the Unicode string, but should be pointer to
8bit ASCII string.

RBS

On Thu, Oct 8, 2015 at 9:58 AM, Bart Smissaert 
wrote:

> OK, thanks, at least I know that the function works fine then in
> sqlite3.dll.
> Problem must be on my side then.
>
> This is the code in the Std_Call dll:
>
> SQLITE3_STDCALL_API const char * __stdcall sqlite3_stdcall_db_filename(sqlite3
> *pDb, const char *zDbName)
> {
> return sqlite3_db_filename(pDb, zDbName);
> }
>
> And this is the Declare in VBA:
>
> Public Declare Function sqlite3_stdcall_db_filename Lib "SQLite3_StdCall"
> Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
> lPtrAttachedDBName As Long) As Long
>
> Anything wrong with either of these?
>
>
> RBS
>
>
>
>
> On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy  wrote:
>
>> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
>>
>>> As I understand it this should produce a filepointer to the filepath of
>>> the
>>> attached database, given the database handle of file the other database
>>> was
>>> attached to and the database name of the attached database. I checked all
>>> the return values and also did a select involving tables in both
>>> databases and all goes fine, so I can be sure that the other database is
>>> attached OK.
>>> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
>>> error messages though.
>>>
>>> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
>>> in VBA here.
>>>
>>> Any suggestions what could be the problem?
>>>
>>> I am running 3.8.11.1
>>>
>>>
>> The program below works here.
>>
>> I'm seeing full paths for databases "main" and "aux", and a zero-length
>> nul-terminated string for "next" (the in-memory database).
>>
>> Dan
>>
>> -
>>
>>
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char **argv){
>>   int rc;
>>   sqlite3 *db;
>>
>>   rc = sqlite3_open("test.db", );
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
>>   if( rc!=SQLITE_OK ){
>> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
>> exit(1);
>>   }
>>
>>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
>>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
>>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
>>
>>   return 0;
>> }
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>

[sqlite] Can this be done in SQLite?

[Hody Crouch]

You should be able to concatenate the first and last name in a subquery and
then use group_concat to output the single column you describe.

For example:

select group_concat(clientname, ';') from (select FirstName || ',' ||
LastName from yourtable);

On Thu, Oct 8, 2015 at 4:54 PM, K. P.  wrote:

> Thanks for that.I'd need something along the lines of
>
> group_concat(c.LastName || ', ' || c.FirstName, ';') as ClientName,
>
>
> which in itself does not seem to be supported.
>
>
> c.LastName || ', ' || c.FirstName, ';') as FullName,
> group_concat(FullName, ';') as ClientName,
>
>
> also not :(
>
>
> Any way around this?
>
>
>
>
>
> > From: slavins at bigfraud.org
> > Date: Thu, 8 Oct 2015 17:01:06 +0100
> > To: sqlite-users at mailinglists.sqlite.org
> > Subject: Re: [sqlite] Can this be done in SQLite?
> >
> >
> > On 8 Oct 2015, at 4:59pm, K. P.  wrote:
> >
> > > Given the following tables, is it possible to extract rows of class
> data along with all participating student names concatenated in one column
> in a single SQL query?
> >
> > See the 'group_concat()' function:
> >
> > 
> >
> > Simon.
> > ___
> > sqlite-users mailing list
> > sqlite-users at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] Can this be done in SQLite?

[Simon Slavin]

On 8 Oct 2015, at 4:59pm, K. P.  wrote:

> Given the following tables, is it possible to extract rows of class data 
> along with all participating student names concatenated in one column in a 
> single SQL query?

See the 'group_concat()' function:



Simon.

[sqlite] Explain query plan bug: overflow of subquery_id

[Alexander Kass]

As for version 3.8.6, when executing:

sqlite> explain query plan with a as (
  SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION
ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION
ALL SELECT 1 UNION ALL
  SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION
ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
)
select * from a, a a1, a a2, a a3, a a4, a a5, a a6, a a7, a a8, a a9, a
a10, a a11, a a12, a a13, a a14, a a15;

I got output:


0|0|0|SCAN SUBQUERY 1
0|1|1|SCAN SUBQUERY 32 AS a1
0|2|2|SCAN SUBQUERY 63 AS a2
0|3|3|SCAN SUBQUERY 94 AS a3
0|4|4|SCAN SUBQUERY 125 AS a4
0|5|5|SCAN SUBQUERY 156 AS a5
0|6|6|SCAN SUBQUERY 187 AS a6
0|7|7|SCAN SUBQUERY 218 AS a7
0|8|8|SCAN SUBQUERY 249 AS a8
0|9|9|SCAN SUBQUERY 24 AS a9
0|10|10|SCAN SUBQUERY 55 AS a10
0|11|11|SCAN SUBQUERY 86 AS a11
0|12|12|SCAN SUBQUERY 117 AS a12
0|13|13|SCAN SUBQUERY 148 AS a13
0|14|14|SCAN SUBQUERY 179 AS a14
0|15|15|SCAN SUBQUERY 210 AS a15

Which is wrong: every subquery_id after "SCAN SUBQUERY" is displayed mod
256, while displayed normally in other lines, involving subquery_id


-- 
Best regards,
Alexander Kass

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Bert Huijben]

> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin
> Sent: donderdag 8 oktober 2015 16:36
> To: General Discussion of SQLite Database  users at mailinglists.sqlite.org>
> Subject: Re: [sqlite] Proposed new version numbering scheme for SQLite -
> Feedback requested
> 
> 
> On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:
> 
> > If accepted, the new policy will cause the next release to be 3.9.0
> > instead of 3.8.12.  And the second number in the version will be
> > increased much more aggressively in future releases.
> 
> I approve of this particular release changing the Y value (i.e. being
3.9.0) since
> it allows SQLite to create and change databases to a format which can't be
> opened with previous versions.
> 
> "However, the current tarball naming conventions only reserve two digits
for
> the Y and so the naming format for downloads will need to be revised in
> about 2030."
> 
> If we're still actively using SQLite3 for new projects in 2030 (i.e. we
haven't
> moved on to SQLite4 or something else entirely), they'd better award the
> dev team a solid platinum prize of some sort.

+1

Bert Huijben

BTW: Completed the Subversion testsuite on the 3.8.12 version. No problems
found.

[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing

[Filip Navara]

All the extensions have to be explicitly enabled by compile-time flags.
This is the case for FTS3/4, which has been included in the amalgamation
for several years. The RTree and also the new JSON extension are included
as well. It only seems logical that FTS5 should be included too as it is
part of official releases.

F.

On Thu, Oct 8, 2015 at 4:01 PM, Hick Gunter  wrote:

> I expect users running SQLite on embedded devices would be thrilled...
>
> -Urspr?ngliche Nachricht-
> Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:
> sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Filip Navara
> Gesendet: Donnerstag, 08. Oktober 2015 15:55
> An: sqlite-dev at mailinglists.sqlite.org
> Cc: General Discussion of SQLite Database
> Betreff: Re: [sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing
>
> Would it be possible to include FTS5 in the amalgamation?
>
> Thanks,
> Filip Navara
>
> On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp  wrote:
>
> > The release checklist for version 3.8.12
> > (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> > 3.8.12 release will occur when the checklist goes all-green.
> >
> > A preliminary change log for version 3.8.12 can be seen at
> > https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> > documentation can be seen at https://www.sqlite.org/draft/
> >
> > If you have issues or concerns with the current SQLite trunk, please
> > speak up *now*.
> >
> > --
> > D. Richard Hipp
> > drh at sqlite.org
> > ___
> > sqlite-dev mailing list
> > sqlite-dev at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev
> >
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
> ___
>  Gunter Hick
> Software Engineer
> Scientific Games International GmbH
> FN 157284 a, HG Wien
> Klitschgasse 2-4, A-1130 Vienna, Austria
> Tel: +43 1 80100 0
> E-Mail: hick at scigames.at
>
> This communication (including any attachments) is intended for the use of
> the intended recipient(s) only and may contain information that is
> confidential, privileged or legally protected. Any unauthorized use or
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please immediately notify the sender
> by return e-mail message and delete all copies of the original
> communication. Thank you for your cooperation.
>
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] Can this be done in SQLite?

[K. P.]

Given the following tables, is it possible to extract rows of class data along 
with all participating student names concatenated in one column in a single SQL 
query?

Classes---IDDateSubject

ParticipantsIDClassIDStudentID

StudentsIDName
As always, thanks for any help on this! 
  

[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing

[Filip Navara]

Would it be possible to include FTS5 in the amalgamation?

Thanks,
Filip Navara

On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp  wrote:

> The release checklist for version 3.8.12
> (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> 3.8.12 release will occur when the checklist goes all-green.
>
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.
>
> --
> D. Richard Hipp
> drh at sqlite.org
> ___
> sqlite-dev mailing list
> sqlite-dev at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev
>

[sqlite] Problem with sqlite3_db_filename

[Dan Kennedy]

On 10/08/2015 03:51 AM, Bart Smissaert wrote:
> As I understand it this should produce a filepointer to the filepath of the
> attached database, given the database handle of file the other database was
> attached to and the database name of the attached database. I checked all
> the return values and also did a select involving tables in both
> databases and all goes fine, so I can be sure that the other database is
> attached OK.
> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
> error messages though.
>
> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
> in VBA here.
>
> Any suggestions what could be the problem?
>
> I am running 3.8.11.1
>

The program below works here.

I'm seeing full paths for databases "main" and "aux", and a zero-length 
nul-terminated string for "next" (the in-memory database).

Dan

-



#include 
#include 
#include 

int main(int argc, char **argv){
   int rc;
   sqlite3 *db;

   rc = sqlite3_open("test.db", );
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
   if( rc!=SQLITE_OK ){
 fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
 exit(1);
   }

   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));

   return 0;
}

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Simon Slavin]

On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:

> If accepted, the new policy will cause the next release to be 3.9.0
> instead of 3.8.12.  And the second number in the version will be
> increased much more aggressively in future releases.

I approve of this particular release changing the Y value (i.e. being 3.9.0) 
since it allows SQLite to create and change databases to a format which can't 
be opened with previous versions.

"However, the current tarball naming conventions only reserve two digits for 
the Y and so the naming format for downloads will need to be revised in about 
2030."

If we're still actively using SQLite3 for new projects in 2030 (i.e. we haven't 
moved on to SQLite4 or something else entirely), they'd better award the dev 
team a solid platinum prize of some sort.

Simon.

[sqlite] version 3.9.0 doc errors

[Donald Griggs]

Regarding:
  2nd paragraph - The New Version Numbering System (auxiliary letter):
"The second number Y is incremented for any change that breaks forward*s*
compatibility..."

Not that it matters much, but in general it seems that adding the "s" to
backward and forward is more often done in British English vs American.

Also, backward is said to be more used for the adjective and backwardS when
used as an adverb.

http://www.quickanddirtytips.com/education/grammar/backward-versus-backwards

On Thu, Oct 8, 2015 at 2:11 PM, R.Smith  wrote:

> More draft doc errors:
> https://www.sqlite.org/draft/versionnumbers.html
>
> 1st paragraph - SQLite Version Numbers (typo for "through"):
> "There are two strategies for version numbers in SQLite. The historical
> system, in use from the first release on 2000-08-17 *though* version
> 3.8.11.1 on..."
>
> ---
>
> 2nd paragraph - The New Version Numbering System (auxiliary letter):
> "The second number Y is incremented for any change that breaks forward*s*
> compatibility..."
>
> ---
>
> In https://www.sqlite.org/draft/releaselog/3_9_0.html
> New features and enhancements (grammar typo):
> "Enhance the dbstat virtual table so that it can be used as a table-valued
> functions where..."
>
> I think it meant to read like this:
> "Enhance*d* the dbstat virtual table so that it can be used as a
> table-valued *function* where..."
>
> ---
>
>
> Cheers,
> Ryan
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing

[Hick Gunter]

I expect users running SQLite on embedded devices would be thrilled...

-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Filip 
Navara
Gesendet: Donnerstag, 08. Oktober 2015 15:55
An: sqlite-dev at mailinglists.sqlite.org
Cc: General Discussion of SQLite Database
Betreff: Re: [sqlite] [sqlite-dev] SQLite version 3.8.12 enters testing

Would it be possible to include FTS5 in the amalgamation?

Thanks,
Filip Navara

On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp  wrote:

> The release checklist for version 3.8.12
> (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> 3.8.12 release will occur when the checklist goes all-green.
>
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.
>
> --
> D. Richard Hipp
> drh at sqlite.org
> ___
> sqlite-dev mailing list
> sqlite-dev at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev
>
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: hick at scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

On 10/8/15, Scott Robison  wrote:
>
> 3.1.0 is released
> 3.1.1 fixes a bug in 3.1
> 3.2.0 is released with new features.
> 3.2.1 fixes a bug originally introduced in 3.1.0
>
> Some people are going to expect that bug fix to be back ported into the 3.1
> branch and have a 3.1.2 release cut from it.
>

The SQLite developers are happy to do this kind of backporting at the
request of SQLite Consortium members and Technical Support customers.
 ;-)

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Stephen Chrzanowski]

I'd add the disclaimer to the page that once 3.2.0 is built, 3.1.x becomes
inert and any fixes pertaining to that particular release belongs to the
3.2.* release.  "Lawyer speak", I guess one could coin it.

What the "Effect Definition" is of what Major and Minor is, I think Richard
draft page has it.  If a database made today can't be open by tomorrows
release, then Y+1;Z=0, otherwise, Z+1.  If something was found to be broken
in Y-5 and now fixed, then the new build would be just Z+1.

2050  Seems just around the corner

On Thu, Oct 8, 2015 at 12:32 PM, Scott Robison 
wrote:

> On Thu, Oct 8, 2015 at 10:21 AM, Richard Hipp  wrote:
>
> > To look at it another way, in version X.Y.Z, it has always been the
> > case and will remain the case that Y is incremented for major changes
> > and Z is incremented for minor changes.  The proposed policy change is
> > to alter the definition of "major" and "minor" such that *anything*
> > other than a simple bug fix of a few lines is considered a "major"
> > change.  Formerly, "major" changes were things like adding WAL mode or
> > rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
> > and partial indexes were all considered "minor" changes.
> >
> > It all really boils down to this:  What is the difference between a
> > "major" and a "minor" change?
> >
>
> A "minor" change has to my way of thinking always been about "this fixes
> something that wasn't working as intended".
>
> One potential downside (based on a previous comment in this thread) I can
> see to going to a more "semantic versioning compliant" model is the
> expectation that some people might have that every 3.y release will be
> maintained with bug fixes / z level patches. For example:
>
> 3.1.0 is released
> 3.1.1 fixes a bug in 3.1
> 3.2.0 is released with new features.
> 3.2.1 fixes a bug originally introduced in 3.1.0
>
> Some people are going to expect that bug fix to be back ported into the 3.1
> branch and have a 3.1.2 release cut from it.
>
> --
> Scott Robison
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

On 10/8/15, Stephen Chrzanowski  wrote:
>
> What the minor and build versions mean is subject to change and offer an
> air of confusion.  With a 3.{Date} version, you get a concrete "This is the
> day the product was built with all features and known bug fixes".  And it'd
> be just as easy for people to report "Between 201510081205 and 201512101500
> I have this problem..."  Bit harder to read, come to think of it.

SQLite already offers date-based versioning as an alternative.  See
the sqlite3_sourceid() interface and the SQLITE_SOURCE_ID macro, both
of which begin with the ISO8601 date.

The sqlite3_libversion_number() interface and the
SQLITE_VERSION_NUMBER macro depend on the old-style X.Y.Z version
numbers though.  And lots of legacy code depends on those interfaces,
so they need to continue to be supported moving forward.

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

To look at it another way, in version X.Y.Z, it has always been the
case and will remain the case that Y is incremented for major changes
and Z is incremented for minor changes.  The proposed policy change is
to alter the definition of "major" and "minor" such that *anything*
other than a simple bug fix of a few lines is considered a "major"
change.  Formerly, "major" changes were things like adding WAL mode or
rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
and partial indexes were all considered "minor" changes.

It all really boils down to this:  What is the difference between a
"major" and a "minor" change?

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Stephen Chrzanowski]

I'm indifferent, to be quite honest, how the version numbers work and what
I download, so long that there is a difference and things become more solid
with both enhancements and fixes..  Set the file name and revisions to a
date, for all that it matters to me, or just label is as
SQLite3.dll/.zip/.so/.etc.  But I'm kind of siding on what Marc is getting
at.

Lets say that a new function is added.  Y gets bumped to Y+1 (Call it Y1)
and Z is reset to 0.
Another new function is added, Y gets bumped again to Y+1 (Call it Y2) and
Z is again reset to 0 and now Y1 is considered irrelevant.
What happens when something is discovered wrong with the first function?
This update to the function introduced in Y1 doesn't have anything to do
with Y2, so is Z going to get bumped?

(This is my personal general conundrum with how team based revision systems
work with GIT, SVN, and now even Fossil.  If something found new today that
was introduced three revisions ago, whats the count get set to?)

My $0.02 comes down to scrap the whole major/minor/build version system and
go with something more concrete using build dates.  So 3.201508151235.
This would point that 3 is for file structure for SQLite3 while the build
date contains whatever has been put into code.  At the source code level
for individual files, my SCR automatically bumps up the version number.
All in all, with single or multiple changes, only affects the final output
of the build process.

What the minor and build versions mean is subject to change and offer an
air of confusion.  With a 3.{Date} version, you get a concrete "This is the
day the product was built with all features and known bug fixes".  And it'd
be just as easy for people to report "Between 201510081205 and 201512101500
I have this problem..."  Bit harder to read, come to think of it.

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

On 10/8/15, Marc L. Allen  wrote:
> However, CTE is a functionality enhancement that, I believe, does not impact
> the ability of previous SQLite versions to work with the database.  The
> thing is, I don't believe CTE is simply a "performance enhancement."  To me,
> a "performance enhancement" provides no new functionality, but just works
> better.
>

If someone does (for example):

   CREATE VIEW digits AS
  WITH RECURSIVE c(x) AS (VALUES(0) UNION ALL SELECT x+1 FROM c WHERE x<9)
  SELECT x FROM c;

Then the CTE becomes part of the schema, and the database cannot be
opened by an earlier version of SQLite that lacks support for CTEs.

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Igor Tandetnik]

On 10/8/2015 11:51 AM, Marc L. Allen wrote:
> However, CTE is a functionality enhancement that, I believe, does not impact 
> the ability of previous SQLite versions to work with the database.

One could create a view, or a trigger, that uses CTE query. That's not 
backward-compatible. Basically, any query could in principle become part 
of the schema.
-- 
Igor Tandetnik

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Marc L. Allen]

Ah.  Of course.

Thanks for waking me up.. both you and Igor.

-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp
Sent: Thursday, October 08, 2015 12:12 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for 
SQLite - Feedback requested

On 10/8/15, Marc L. Allen  wrote:
> However, CTE is a functionality enhancement that, I believe, does not 
> impact the ability of previous SQLite versions to work with the 
> database.  The thing is, I don't believe CTE is simply a "performance 
> enhancement."  To me, a "performance enhancement" provides no new 
> functionality, but just works better.
>

If someone does (for example):

   CREATE VIEW digits AS
  WITH RECURSIVE c(x) AS (VALUES(0) UNION ALL SELECT x+1 FROM c WHERE x<9)
  SELECT x FROM c;

Then the CTE becomes part of the schema, and the database cannot be opened by 
an earlier version of SQLite that lacks support for CTEs.

--
D. Richard Hipp
drh at sqlite.org
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.

[sqlite] SQLite version 3.8.12 enters testing

[Zsbán Ambrus]

On Wed, Oct 7, 2015 at 9:42 PM, Richard Hipp  wrote:
> On 10/7/15, Zsb?n Ambrus  wrote:
> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

Thanks, that's much better.  The
"http://sqlite.org/draft/expridx.html; documentation tells all I
wanted to know.  However, it seems you forgot to link that
documentation from "http://sqlite.org/draft/docs.html; .  It should
probably be linked from under the heading "SQLite Features and
Extensions".

There is one apparent inconsistency I was wondering about.  For a
partial index, the WHERE clause of the index cannot contain functions;
whereas for an index on an expression, the expression can contain
deterministic functions.  What is the explanation of this difference?
Is it only historical, because the deterministic functions flag is a
new addition?

Ambrus

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Scott Robison]

On Thu, Oct 8, 2015 at 10:53 AM, Richard Hipp  wrote:

> On 10/8/15, Scott Robison  wrote:
> >
> > 3.1.0 is released
> > 3.1.1 fixes a bug in 3.1
> > 3.2.0 is released with new features.
> > 3.2.1 fixes a bug originally introduced in 3.1.0
> >
> > Some people are going to expect that bug fix to be back ported into the
> 3.1
> > branch and have a 3.1.2 release cut from it.
> >
>
> The SQLite developers are happy to do this kind of backporting at the
> request of SQLite Consortium members and Technical Support customers.
>  ;-)
>

Well of course! But this is the internet, everything is supposed to be free
and exactly as you want it! :)

-- 
Scott Robison

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Marc L. Allen]

More thoughts...

My quandary is with compatibility in regards to file formats only.  If you 
extend it to API, the CTE would require a Y change.  Code that uses SQLite and 
runs with Y may not operate with Y-1 API.

And, on a side note... the new versioning scheme also means that changes, such 
as the new Query Analyzer done a few years back (which was a huge boost in 
performance) would be relegated to a Z change, which makes me sad. ;)

-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Marc L. Allen
Sent: Thursday, October 08, 2015 11:52 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for 
SQLite - Feedback requested

Just my $0.02...

In the proposed new versioning system:

Partial Indexes is clearly something that requires Y to be incremented as Y-1 
won't be able to handle a database with partial indexes.

However, CTE is a functionality enhancement that, I believe, does not impact 
the ability of previous SQLite versions to work with the database.  The thing 
is, I don't believe CTE is simply a "performance enhancement."  To me, a 
"performance enhancement" provides no new functionality, but just works better.

So, I question the exact definition for 'Z'.  I think it's pretty much any 
change that doesn't mandate X or Y changing.  Maybe change it to:

"The third number Z is incremented for all other changes, such as performance 
enhancements and bug fixes."

-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Jaroslaw 
Staniek
Sent: Thursday, October 08, 2015 11:33 AM
To: sqlite-dev at mailinglists.sqlite.org
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for 
SQLite - Feedback requested

On 8 October 2015 at 15:38, Richard Hipp  wrote:

> Several users have proposed that SQLite adopt a new version numbering 
> scheme.  The proposed change is currently uploaded on the "draft"
> website:
>
> https://www.sqlite.org/draft/versionnumbers.html
> https://www.sqlite.org/draft/releaselog/3_9_0.html
> https://www.sqlite.org/draft/
>
> If accepted, the new policy will cause the next release to be 3.9.0 
> instead of 3.8.12.  And the second number in the version will be 
> increased much more aggressively in future releases.
>
> Your feedback on the proposed policy change is appreciated.  We will 
> delay the next release until there is a semblance of consensus on the 
> new policy.
>

?Thanks, looks solid for me.

PS: For cmake users I am committing myself to update the FindSqlite.cmake 
detection script in areas where it's needed.
Even for the current versioning approach I introduced SQLITE_MIN_VERSION_PATCH 
variable among others.[1] Its semantics can be easily made compatible with the 
proposed new versioning approach by making the variable optional. I welcome any 
further suggestions, also contributing the file to cmake itself since SQLite is 
so popular.

[1]
https://phabricator.kde.org/diffusion/KDB/browse/master/cmake/modules/FindSqlite.cmake

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org 
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi Qt Certified 
Specialist:
: http://www.linkedin.com/in/jstaniek
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Marc L. Allen]

Just my $0.02...

In the proposed new versioning system:

Partial Indexes is clearly something that requires Y to be incremented as Y-1 
won't be able to handle a database with partial indexes.

However, CTE is a functionality enhancement that, I believe, does not impact 
the ability of previous SQLite versions to work with the database.  The thing 
is, I don't believe CTE is simply a "performance enhancement."  To me, a 
"performance enhancement" provides no new functionality, but just works better.

So, I question the exact definition for 'Z'.  I think it's pretty much any 
change that doesn't mandate X or Y changing.  Maybe change it to:

"The third number Z is incremented for all other changes, such as performance 
enhancements and bug fixes."

-Original Message-
From: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Jaroslaw 
Staniek
Sent: Thursday, October 08, 2015 11:33 AM
To: sqlite-dev at mailinglists.sqlite.org
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] [sqlite-dev] Proposed new version numbering scheme for 
SQLite - Feedback requested

On 8 October 2015 at 15:38, Richard Hipp  wrote:

> Several users have proposed that SQLite adopt a new version numbering 
> scheme.  The proposed change is currently uploaded on the "draft"
> website:
>
> https://www.sqlite.org/draft/versionnumbers.html
> https://www.sqlite.org/draft/releaselog/3_9_0.html
> https://www.sqlite.org/draft/
>
> If accepted, the new policy will cause the next release to be 3.9.0 
> instead of 3.8.12.  And the second number in the version will be 
> increased much more aggressively in future releases.
>
> Your feedback on the proposed policy change is appreciated.  We will 
> delay the next release until there is a semblance of consensus on the 
> new policy.
>

?Thanks, looks solid for me.

PS: For cmake users I am committing myself to update the FindSqlite.cmake 
detection script in areas where it's needed.
Even for the current versioning approach I introduced SQLITE_MIN_VERSION_PATCH 
variable among others.[1] Its semantics can be easily made compatible with the 
proposed new versioning approach by making the variable optional. I welcome any 
further suggestions, also contributing the file to cmake itself since SQLite is 
so popular.

[1]
https://phabricator.kde.org/diffusion/KDB/browse/master/cmake/modules/FindSqlite.cmake

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org 
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi Qt Certified 
Specialist:
: http://www.linkedin.com/in/jstaniek
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.

[sqlite] [sqlite-dev] Proposed new version numbering scheme for SQLite - Feedback requested

[Scott Robison]

On Thu, Oct 8, 2015 at 10:21 AM, Richard Hipp  wrote:

> To look at it another way, in version X.Y.Z, it has always been the
> case and will remain the case that Y is incremented for major changes
> and Z is incremented for minor changes.  The proposed policy change is
> to alter the definition of "major" and "minor" such that *anything*
> other than a simple bug fix of a few lines is considered a "major"
> change.  Formerly, "major" changes were things like adding WAL mode or
> rewriting the query planner, and adding WITHOUT ROWID tables, CTEs,
> and partial indexes were all considered "minor" changes.
>
> It all really boils down to this:  What is the difference between a
> "major" and a "minor" change?
>

A "minor" change has to my way of thinking always been about "this fixes
something that wasn't working as intended".

One potential downside (based on a previous comment in this thread) I can
see to going to a more "semantic versioning compliant" model is the
expectation that some people might have that every 3.y release will be
maintained with bug fixes / z level patches. For example:

3.1.0 is released
3.1.1 fixes a bug in 3.1
3.2.0 is released with new features.
3.2.1 fixes a bug originally introduced in 3.1.0

Some people are going to expect that bug fix to be back ported into the 3.1
branch and have a 3.1.2 release cut from it.

-- 
Scott Robison

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Scott Robison]

On Thu, Oct 8, 2015 at 8:36 AM, Simon Slavin  wrote:

>
> On 8 Oct 2015, at 2:38pm, Richard Hipp  wrote:
>
> > If accepted, the new policy will cause the next release to be 3.9.0
> > instead of 3.8.12.  And the second number in the version will be
> > increased much more aggressively in future releases.
>
> I approve of this particular release changing the Y value (i.e. being
> 3.9.0) since it allows SQLite to create and change databases to a format
> which can't be opened with previous versions.
>

+1

I really don't object to a more "Semantic Versioning" release, but I think
those who really want it are fooling themselves into thinking it will
require less mental effort. Still, it doesn't hurt me or help me to stick
with one or change to the other.


> "However, the current tarball naming conventions only reserve two digits
> for the Y and so the naming format for downloads will need to be revised in
> about 2030."
>
> If we're still actively using SQLite3 for new projects in 2030 (i.e. we
> haven't moved on to SQLite4 or something else entirely), they'd better
> award the dev team a solid platinum prize of some sort.
>

If this change is being made at this time, why not just go ahead and make a
tarball naming convention change now too. Symlinks could easily accommodate
the current convention for as long as is needed / desired. Given the fact
that the last two digits of the current tarball naming convention will
forever after be 00:

filename-3XXYYZZ.ext means filename-3YYZZ00.ext

Go ahead and either start using:

filename-3YYYZZZ.ext (note below)

Or alternatively:

filename-3-Y-Z.ext (or some variation thereof)

The 3YYYZZZ format has two potential flaws. One is the relative sort order,
in that field widths are different in length and quantity. Any future
change will have this problem, so I ignore it.

The other is potential collisions with previous releases. They should be
relatively rare. They can be completely avoided with something more like
filename-3YYYZZZb.ext (or any other character in place of b to indicate it
is part of a different sequence; it can be prefixed or suffixed to the
version number string depending on preferences).

-- 
Scott Robison

[sqlite] Strange behaviour of IN/NOT IN subqueries?

[Hick Gunter]

Indeed you did reproduce in that you selected all of the 1 entries you inserted 
into table item and inadvertently used the field name from the table in the 
subquery in the NOT IN case ;)

A subquery "select itemcode from tmp_salesitm", is allowed to refer to fields 
from the outer "select * from item" , making it a correlated subquery.

Since there is no where clause, the subquery will return the correlated field 
itemcode (as opposed to it's native field itemid) exactly once for each row it 
contains.

Adding the same element to a set n>0 times is no different than adding the 
element to the set exactly once, so the IN set has, for each execution, one 
element and the expression  IN () is always true.

As duly noted  IN () is logically equivalent to  == , but 
inherently very much slower in execution because SQLite does not check/optimize 
for this edge case.


-Urspr?ngliche Nachricht-
Von: sqlite-users-bounces at mailinglists.sqlite.org 
[mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Igor 
Tandetnik
Gesendet: Mittwoch, 07. Oktober 2015 19:52
An: sqlite-users at mailinglists.sqlite.org
Betreff: Re: [sqlite] Strange behaviour of IN/NOT IN subqueries?

On 10/7/2015 10:40 AM, Constantine Yannakopoulos wrote:
> I have two tables, "item" (items on sale) where a column named "itemcode"
> is the PK and "tmp_salesitm" (invoice item lines) where the foreign
> key column to "item" is called "itemid" and not "itemcode" for some
> reason. I wanted to find all records from the first with no matching
> records in the second (i.e. items that have never been sold). So I hastily 
> typed:
>
>select * from item where itemcode not in (select itemcode from
> tmp_salesitm)
>
> forgetting that the column name was different. To my amazement the
> query returned ALL rows from table "item"

Can't reproduce.

sqlite> create table item(itemcode integer); insert into item(itemcode)
sqlite> values (1); create table tmp_salesitm(itemid integer); insert
sqlite> into tmp_salesitm(itemid) values (100);  select * from item
sqlite> where itemcode not in (select itemcode from
tmp_salesitm);
sqlite>  select * from item where itemcode not in (select itemid from
tmp_salesitm);
1
sqlite> select * from item where itemcode in (select itemcode from
tmp_salesitm);
1

> So I wondered, shouldn't the first query throw an error

No it should not. The query is valid, if meaningless. The correlated subquery 
is allowed to use columns from the enclosing query's tables.

> instead of returning a result that does not make sense?

It's not up to the engine to determine whether or not a query would make sense 
to a human. Its job is to check whether the query is syntactically valid, then 
execute it as written.

> Then I thought that the SQL
> parser may have interpreted "itemcode" in the subquery as a reference
> to the "itemcode" column of the outer query.

That's what happens, yes.

> My question is, is this behaviour normal? Should a NOT IN subquery,
> that uses a different from clause and is -to my knowledge- not
> correlated, be allowed to select columns of the outer query's FROM tables?

What, in your opinion, is the definition of "correlated subquery", if not "a 
subquery that happens to be using columns from the outer query"?

> Shouldn't an
> error be raised instead or am I missing something?

You are missing something.

> FYI the outcome is similar if I replace "NOT IN" with "IN". With:
>
>select * from item where itemcode in (select itemcode from
> tmp_salesitm)
>
> I get zero records

For me, it works the other way round (as I would expect). IN return all 
records, since it's essentially equivalent to

select * from item where itemcode = itemcode;

NOT IN returns no records, since it's essentially equivalent to

select * from item where itemcode != itemcode;

Are you sure you are not mixing up the two?
--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick
Software Engineer
Scientific Games International GmbH
FN 157284 a, HG Wien
Klitschgasse 2-4, A-1130 Vienna, Austria
Tel: +43 1 80100 0
E-Mail: hick at scigames.at

This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is confidential, 
privileged or legally protected. Any unauthorized use or dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the sender by return e-mail message and 
delete all copies of the original communication. Thank you for your cooperation.

[sqlite] Problem with sqlite3_db_filename

[Bart Smissaert]

OK, thanks, at least I know that the function works fine then in
sqlite3.dll.
Problem must be on my side then.

This is the code in the Std_Call dll:

SQLITE3_STDCALL_API const char * __stdcall sqlite3_stdcall_db_filename(sqlite3
*pDb, const char *zDbName)
{
return sqlite3_db_filename(pDb, zDbName);
}

And this is the Declare in VBA:

Public Declare Function sqlite3_stdcall_db_filename Lib "SQLite3_StdCall"
Alias "_sqlite3_stdcall_db_filename at 8" (ByVal hDBHandle As Long, ByVal
lPtrAttachedDBName As Long) As Long

Anything wrong with either of these?


RBS




On Thu, Oct 8, 2015 at 9:40 AM, Dan Kennedy  wrote:

> On 10/08/2015 03:51 AM, Bart Smissaert wrote:
>
>> As I understand it this should produce a filepointer to the filepath of
>> the
>> attached database, given the database handle of file the other database
>> was
>> attached to and the database name of the attached database. I checked all
>> the return values and also did a select involving tables in both
>> databases and all goes fine, so I can be sure that the other database is
>> attached OK.
>> All I get from sqlite3_db_filename is zero, so no valid file pointer. No
>> error messages though.
>>
>> I am accessing sqlite3.dll (Windows 7) via a std_call dll as I am working
>> in VBA here.
>>
>> Any suggestions what could be the problem?
>>
>> I am running 3.8.11.1
>>
>>
> The program below works here.
>
> I'm seeing full paths for databases "main" and "aux", and a zero-length
> nul-terminated string for "next" (the in-memory database).
>
> Dan
>
> -
>
>
>
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv){
>   int rc;
>   sqlite3 *db;
>
>   rc = sqlite3_open("test.db", );
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_open: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   rc = sqlite3_exec(db, "ATTACH 'other.db' AS 'aux'", 0, 0, 0);
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   rc = sqlite3_exec(db, "ATTACH ':memory:' AS 'next'", 0, 0, 0);
>   if( rc!=SQLITE_OK ){
> fprintf(stderr, "sqlite3_exec: %s\n", sqlite3_errmsg(db));
> exit(1);
>   }
>
>   printf("main  db is: %s\n", sqlite3_db_filename(db, "main"));
>   printf("aux   db is: %s\n", sqlite3_db_filename(db, "aux"));
>   printf("next  db is: %s\n", sqlite3_db_filename(db, "next"));
>
>   return 0;
> }
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] SQLite version 3.8.12 enters testing

[Dominique Devienne]

On Wed, Oct 7, 2015 at 11:01 PM, R.Smith  wrote:

> [...] (Brilliant release btw, thanks)
>

+1


> [...] This definitely feels like a 3.9 release rather than a 3.8.12. I
> mean it introduces functionality that a 3.8.11 engine won't be able to
> comprehend - and not just one obscure item either.
>

That alone warrants a 3.9 IMHO. Totally agree with Ryan.

And I think his point that any release that introduces a new feature, which
if used, makes prior version not being able to use the DB, a good rule of
thumb to decide whether to bump MINOR or not.

FWIW. My $0.02. Etc... :) --DD

[sqlite] Proposed new version numbering scheme for SQLite - Feedback requested

[Richard Hipp]

Several users have proposed that SQLite adopt a new version numbering
scheme.  The proposed change is currently uploaded on the "draft"
website:

https://www.sqlite.org/draft/versionnumbers.html
https://www.sqlite.org/draft/releaselog/3_9_0.html
https://www.sqlite.org/draft/

If accepted, the new policy will cause the next release to be 3.9.0
instead of 3.8.12.  And the second number in the version will be
increased much more aggressively in future releases.

Your feedback on the proposed policy change is appreciated.  We will
delay the next release until there is a semblance of consensus on the
new policy.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

On 10/8/15, Zsb?n Ambrus  wrote:
>
> There is one apparent inconsistency I was wondering about.  For a
> partial index, the WHERE clause of the index cannot contain functions;
> whereas for an index on an expression, the expression can contain
> deterministic functions.  What is the explanation of this difference?
> Is it only historical, because the deterministic functions flag is a
> new addition?
>

It is historical.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] version 3.8.12 doc errors

[R.Smith]

Documentation errors:
https://www.sqlite.org/draft/vtab.html#epovtab

In the 1.1.2 Eponymous virtual tables section (auxiliary word):
"Note that SQLite versions prior to 3.8.12 did not check the xCreate 
method for NULL *before to* invoking it..."

---

https://www.sqlite.org/draft/json1.html
under 2.0 Interface overview (missing word: "to")
Backwards compatibility constraints mean that SQLite is only able to 
store values that are NULL, integers, floating-point numbers, text, and 
BLOBs. It is not *possible add* a sixth "JSON" type.

---

under 2.0 still - last paragraph (grammar: Starting a sentence with But):
"...experience is gained, some kind of JSON extension might be folded 
into the SQLite core. But for now, JSON support remains an extension."
Possible alternates:
"...experience is gained, some kind of JSON extension might be folded 
into the SQLite core, but for now, JSON support remains an extension."
"...experience is gained, some kind of JSON extension might be folded 
into the SQLite core. For now, JSON support remains an extension."

---

under 2.3 VALUE arguments, 1st paragraph (grammar - singular verb on 
plural noun)
"Even if the input /value/ *strings looks* like well-formed JSON, they 
are still interpreted as..."

---

under 2.3 VALUE arguments, 3rd paragraph (grammar + punctuation)
"For example, in the following call to json_object(), the /value/ 
argument looks like a well-formed JSON array. But because it is just 
ordinary SQL text it is interpreted as a literal..."
Possible alternate:
"For example, in the following call to json_object(), the /value/ 
argument looks like a well-formed JSON array*, but* because it is just 
ordinary SQL *text,* it is interpreted as a literal..."

---


Cheers,
Ryan

[sqlite] SQLite version 3.8.12 enters testing

[R.Smith]

Some notes on 3.8.12: (Brilliant release btw, thanks)

I've been following the thread about the version numbering, and at first 
thought the OP was a little over-enthusiastic about increasing version 
numbers prematurely, but then after reading the release notes, I have to 
agree to some extent - That is - I am not sure we should be changing the 
way SQLite is versioned altogether, but maybe a bit more prolific in the 
release versions? This definitely feels like a 3.9 release rather than a 
3.8.12. I mean it introduces functionality that a 3.8.11 engine won't be 
able to comprehend - and not just one obscure item either.



The Indexed expressions document 
(https://www.sqlite.org/draft/expridx.html) notes that the expression 
must be exactly reproduced in the query to make use of it (i.e. exactly 
as it was defined in the CREATE INDEX statement).
It goes on to note that "exactly" means syntactically equivalent (not 
mathematically etc.), which is great, and that whitespace does not 
matter. What about Capitalization and quotation?

i.e. - for this schema:

i.e. - for this schema:
CREATE TABLE t2(x,y,z);
CREATE INDEX t2xy ON t2(x+y);

Would these all be equivalent?

SELECT * FROM t2 WHERE X+y=22;
SELECT * FROM t2 WHERE "x" + "y" = 22;
SELECT * FROM t2 WHERE "x" + Y = 22;


Whatever the answer, may it be added to the documentation please? (A 
short example like the above would suffice I think).

-

Documentation error in the Restrictions section (typo):
"2. Expressions in CREATE INDEX *statmeent* may contain function calls, 
but only to functions whose output is always determined completely by 
its..."

--

Documentation error in the Release notes (pluralization):
"Enhance the dbstat virtual table 
 so that it can be used as *a 
table-valued functions 
* where the argument is..."


Thanks,
Ryan