Re: [sqlite] Add support for new arch 'ppc64le' in "sqlite3" upstream package

2014-01-06 Thread ravi 

Hi Richard,

Thanks for the reply. AFAIK, autoconf is used to build configure 
script using different files like configure.ac/in,  *.m4 files.
But the latest *.m4 files can be obtained only with latest automake or 
latest libtool packages.
So, you may have to upgrade the version of automake present in your 
build machine to obtain the latest config.guess and aclocal.m4 files.


Thanks,
Ravindran.

On 01/07/2014 03:15 AM, Richard Hipp wrote:

On Mon, Jan 6, 2014 at 4:29 AM, ravi  wrote:


Hi,

 We are in the process of adding support for new arch -ppc64le (powerpc
64-bit Little Endian) and I was looking at building "sqlite3" pacakge on
ppc64le environment and we found that "sqlite3" package require a patch to
config.guess and aclocal.m4 file.
Fortunatley , automake >=1.13.4 has all the needed bits to support
building on ppc64le arch.


The configure script currently in the source tree was built using autoconf
2.62.  Would it be sufficient to update to a more recent autoconf, or is it
really necessary to figure out and integrate automake?




We want you to upgrade your automake in your build machine to >=1.13.4 and
spin-off a new version of "sqlite3" and let us know the new tar
availability. So that we can test it on ppc64le architecture for you.

the release tarball that we picked is from "http://www.sqlite.org/2013/
sqlite-autoconf-3080200.tar.gz", which doesn'thave the ppc64le support.

Your response is highly appreciated.

--
Ravindran
IBM LinuxTechnologyCenter

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users






--
Ravindran
IBM LinuxTechnologyCenter

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Personal function and parameter evaluation.

2014-01-06 Thread Igor Tandetnik 

On 1/6/2014 6:17 PM, trash Spam wrote:

No, I did not mean anything special.
This is an example. The query may not work there is no table so no type.


Your use of sqlite3_value_text suggested that the function expected a 
string as a parameter.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Personal function and parameter evaluation.

2014-01-06 Thread trash Spam 
No, I did not mean anything special.
This is an example. The query may not work there is no table so no type.


2014/1/6 Igor Tandetnik 

> On 1/6/2014 3:33 PM, trash Spam wrote:
>
>> void myFunc( sqlite3_context* ctx, int nArgs, sqlite3_value** values )
>> {
>> //
>> const char* expr = (const char*)sqlite3_value_text( values[ 0 ] ):
>> //
>> }
>>
>> select
>>   myFunc( col1 + col2 )
>> ;
>>
>> The expression "col1 + col2" is evaluated when i call sqlite3_value_text
>> or
>> before the call of myFunc ?
>>
>
> Before the call to myFunc. I'm pretty sure SQLite doesn't do lazy
> evaluation here.
>
> Also, you probably meant "col1 || col2": '+' does not perform string
> concatenation (unless you do intend to add two numbers, then have SQLite
> convert the result to text).
> --
> Igor Tandetnik
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Add support for new arch 'ppc64le' in "sqlite3" upstream package

2014-01-06 Thread Richard Hipp 
On Mon, Jan 6, 2014 at 4:29 AM, ravi  wrote:

> Hi,
>
> We are in the process of adding support for new arch -ppc64le (powerpc
> 64-bit Little Endian) and I was looking at building "sqlite3" pacakge on
> ppc64le environment and we found that "sqlite3" package require a patch to
> config.guess and aclocal.m4 file.
> Fortunatley , automake >=1.13.4 has all the needed bits to support
> building on ppc64le arch.
>

The configure script currently in the source tree was built using autoconf
2.62.  Would it be sufficient to update to a more recent autoconf, or is it
really necessary to figure out and integrate automake?



>
> We want you to upgrade your automake in your build machine to >=1.13.4 and
> spin-off a new version of "sqlite3" and let us know the new tar
> availability. So that we can test it on ppc64le architecture for you.
>
> the release tarball that we picked is from "http://www.sqlite.org/2013/
> sqlite-autoconf-3080200.tar.gz", which doesn'thave the ppc64le support.
>
> Your response is highly appreciated.
>
> --
> Ravindran
> IBM LinuxTechnologyCenter
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Sqlite as a platform performance comparison tool

2014-01-06 Thread Clemens Ladisch 
Max Vlasov wrote:
> A thought came to compare two computers of different platforms (ie
> i386 vs ARM) using uniform approach. We take two binaries of the same
> sqlite version compiled with the best c compilers for both platforms
> and compare the time spent for identical operations using memory based
> databases (to exclulde I/O from measuring).
>
> Is such comparision correct?

A benchmark measures nothing more than the time needed to execute that
benchmark.

A _good_ benchmark has performance characteristics that are similar to
those of the code you actually intend to run and care about.  Whether
a particular benchmark works well for you is impossible to say without
knowing what you want to measure.

Words like "uniform approach" are meaningless in this context, but I
should mention that I/O is part of the platform, and matters in most
real-world applications.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "Common Table Expression"

2014-01-06 Thread big stone 
The interest of this "forward lateral" move was its good
standardization/effort ratio.

For performance/effort ratio, I would have expect people to push SQLite4
and its 2x to 10x promise.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Personal function and parameter evaluation.

2014-01-06 Thread Igor Tandetnik 

On 1/6/2014 3:33 PM, trash Spam wrote:

void myFunc( sqlite3_context* ctx, int nArgs, sqlite3_value** values )
{
//
const char* expr = (const char*)sqlite3_value_text( values[ 0 ] ):
//
}

select
  myFunc( col1 + col2 )
;

The expression "col1 + col2" is evaluated when i call sqlite3_value_text or
before the call of myFunc ?


Before the call to myFunc. I'm pretty sure SQLite doesn't do lazy 
evaluation here.


Also, you probably meant "col1 || col2": '+' does not perform string 
concatenation (unless you do intend to add two numbers, then have SQLite 
convert the result to text).

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Personal function and parameter evaluation.

2014-01-06 Thread trash Spam 
Hi,

void myFunc( sqlite3_context* ctx, int nArgs, sqlite3_value** values )
{
   //
   const char* expr = (const char*)sqlite3_value_text( values[ 0 ] ):
   //
}

select
 myFunc( col1 + col2 )
;

The expression "col1 + col2" is evaluated when i call sqlite3_value_text or
before the call of myFunc ?

Thank.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] RFE: Rename Column

2014-01-06 Thread Peter Haworth 
>
>
>
> You're both right.  Igor's statement pretty-much /is/ the reason one
> cannot rename a column.  One would need to write a parser and changer for
> SQL statements that could identify and change column names in many
> statements with all sorts of weird possibilities for formatting.
>
> Two alternatives: (a) actually write the parser-and-changer that processes
> SQL commands, or (b) wait until the major file format changes in SQLite4,
> then change the way SQL stores the CREATE commands needed to construct a
> database so it stores a structured version of the commands instead of the
> raw text.
>
> The advantage of either change would be that it allows almost all the
> ALTER TABLE commands SQL users expect, not just changing column names.
>  This simplifies life not just for normal users but also for all the
> writers of SQLite GUI managers out there, who have to write nasty risky
> time-consuming hacks if they want to accomplish those operations.
>
> Simon.
>

SQLiteAdmin is one of those "nasty, risky, time consuming hacks" :-)  It
provides a way to rename a column and deals with changing the name in all
the places it could occur in the database, plus just about any db structure
changes that you'd want to do.  Not as good as a built-in solution
admittedly but it's saved my bacon several times.  If interested, check it
out at www.lcsql.com.  Having written the code, I'd agree with the "nasty"
and "time consuming" adjectives, but not so much the "risky" since all the
changes are done within a transaction and I also offer the option of
backing up the database before making any changes.



Pete
lcSQL Software 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] RFE: Rename Column

2014-01-06 Thread Alek Paunov 

On 06.01.2014 00:58, Simon Slavin wrote:


On 5 Jan 2014, at 6:41pm, Petite Abeille  wrote:

On Jan 5, 2014, at 6:56 PM, Igor Tandetnik  wrote:

On 1/4/2014 7:15 PM, Elrond wrote:

Short: Could you implement alter table rename column?


The problem would be, what to do with all the indexes, triggers, views and 
foreign keys that reference that column?


Sure, but that’s an unrelated set of problems, isn’t it? As it stands, one 
cannot even rename a column.


You're both right.  Igor's statement pretty-much /is/ the reason one cannot 
rename a column.  One would need to write a parser and changer for SQL 
statements that could identify and change column names in many statements with 
all sorts of weird possibilities for formatting.

Two alternatives: (a) actually write the parser-and-changer that processes SQL 
commands, or (b) wait until the major file format changes in SQLite4, then 
change the way SQL stores the CREATE commands needed to construct a database so 
it stores a structured version of the commands instead of the raw text.


If someone have a little time to experiment with the (a) road, it is not 
so complicated as it might look at the first glance: For example sqld3 
[1] is a PEG parser which, as author claims, is derived from the 
SQLite's railroad syntax diagrams, which in order are derived (I 
believe) from the SQLite's sources (i.e. there are chances, that the 
grammar is sound).


PEG [2], is the simplest possible kind of grammar machinery, (probably 
easiest for understanding for non computer language experts) - no 
scanner/parser split, no ambiguity, as people often said - something 
like RegExps on steroids :-).


The above project is in Ruby (is there someone who reads Ruby to give 
some test results?) and it is 3 years old, but this is not so important 
- I think Richard and the team are able to point out even more clever 
path for pure grammar extraction in sync with the latest SQLite sources.


Once a Language grammar is available for given PEG implementation it is 
usually easy to translate it for another - because the PEG rules (for 
the syntax rules :-) ) are basically the same everywhere.


There are hundreds of PEG implementations already - at least several per 
language. My personal favorite is one of the smallest, pure C libs - 
LPeg [3], which just like the SQLite itself compiles the grammar to the 
VM code. LPegLJ [4] port of [3] even does not need a C compiler (the 
source code - it is JIT-ed on demand)


Parsing is the first step. I think, it would be funny if the  dogfooding 
principle for the second - transformation step is tried. i.e. when the 
parse trees of SQlite SQL are stored back in (e.g. in memory) SQlite and 
transformed there ;-).


BTW, transformation relaying on data stores are applied in one of the 
modern products in that field - Rascal [5] (IMP PDB).


Another note: This topic seems somewhat related to the recent 
discussions (e.g. CTEs) about SQLite RFEs which are statically 
implementable (by rewriting, without changes to the SQLite engine)


Kind Regards,
Alek

[1] https://github.com/steveyen/sqld3
[2] http://en.wikipedia.org/wiki/Parsing_expression_grammar
[3] http://www.inf.puc-rio.br/~roberto/lpeg/
[4] https://github.com/sacek/LPegLJ
[5] http://www.rascal-mpl.org/

P.S. @Simon, and others closely following: Please point me to the docs 
for the new style (structured) SQL objects representation in the SQlite4 
- only tables? or scripts too?


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Sqlite as a platform performance comparison tool

2014-01-06 Thread Max Vlasov 
Hi,

A thought came to compare two computers of different platforms (ie
i386 vs ARM) using uniform approach. We take two binaries of the same
sqlite version compiled with the best c compilers for both platforms
and compare the time spent for identical operations using memory based
databases (to exclulde I/O from measuring).

So, we could start with some comparatively large table loaded into
:memory: database and the following operations is going to make
joins/inserts etc probably as a single, semicolon delimited set of
queries. The sets are identical for both platforms and is probably is
best handled with a single sqlite3_exec

Is such comparision correct? So maybe even for memory-based operation
there is something that makes this comparision invalid?

Thanks,

Max
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "Common Table Expression"

2014-01-06 Thread Petite Abeille 
Hello,

On Jan 6, 2014, at 6:51 AM, James K. Lowden  wrote:

> You're welcome to your opinion, of course.  But you're really not answering 
> my point, and I object to your assertion that I'm clinging to 1986.  

Apologies about that. The 1986 reference was more pointed to SQLite itself, not 
you personally :)

> Evolution for its own sake is not improvement, right?

Agree.

>  I simply said that new syntax absent new functionality doesn't add anything, 
> which you haven't denied.  

Yes, agree, it’s a bit of a lateral move at first sight.

> Can we not agree that just toying with the syntax is a waste of time and 
> makes things worse, not better?  

No. This is where we part ways. In this very specific case, introducing named 
subqueries is a great improvement in syntax and flexibility of expression. And 
yes, syntax matters  :)

Think about it more as a compound effect: the ‘with’ clause by itself is not 
much to talk about, but combined with windowing functions (which tend to 
required quite a bit of subqueries) and the ability to decompose logic 
bottom-up (as oppose to inside-out with traditional subqueries) does create a 
much more expressive, comprehensible, and comprehensive language altogether. 

Or at least such is my experience as a practitioner of the dark art of writing 
SQL :D

> Like you, I'd prefer to see SQLite create new functionality,
> not simply offer new keywords to accomplish what it already does.
> There's a case for MERGE and windowing functions, I agree.  Also better
> constraint violation error messages, and bona fide atomic commits.  

Sure thing. More generally, in my opinion, SQLite, the implementation, hasn’t 
keep up with SQL, the ‘standard’. 

> We could have a long, long talk if you wanted to (which I doubt, so I
> won't start) about how well and poorly SQL fits into the modern
> environment, what assumptions it carries forward from the days of COBOL
> and APL and PROLOG.  I know a bit about it.  

I would love to have that talk, but perhaps not over email, which tend to be 
tedious. Perhaps over a drink one day :)

> I'm working on making it obsolete lest my grandchildren have to learn it.  

Like many of its forebears, SQL will outlive us all, with warts, blemishes, and 
all. Best to use it than to fight it in my opinion.

And, on that note, I wish you a Happy New Year.

Cheers,

PA.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Generating sqlite4.c

2014-01-06 Thread Andrew Overholt 

Hi,

I hacked around the build system a bit to get sqlite4.c generating to a 
compilable state.  I've put patch at [1] which is likely completely 
incorrect so I'd love to hear how it should be done :)


In my otherwise clean trunk checkout I'm generating like so:

   $ make -f Makefile.linux-gcc sqlite4.c

The resulting sqlite4 files at least compile and link in Mozilla's gecko 
build system just like our sqlite3 integration (but I haven't yet 
started experimenting with IndexedDB on top of sqlite4).


Thanks and happy new year,

Andrew

[1]
http://people.mozilla.org/~aoverholt/sqlite4-amalgamation.patch
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] RFE: Rename Column

2014-01-06 Thread Elrond 

Hi,

On Sun, Jan 05, 2014 at 22:58:31 +, Simon Slavin wrote:
[...]
> You're both right.  Igor's statement pretty-much /is/ the
> reason one cannot rename a column.  One would need to
> write a parser and changer for SQL statements that could
> identify and change column names in many statements with
> all sorts of weird possibilities for formatting.

Isn't most of the parser already existant, because sqlite
must parse the in-db-schema-sql to know the structure of
the database?
And there already must be code to identify column names in
the parsed structure, for exactly the above named reasons
(checking constraints, checking foreign keys)?

Obviously, the parser is not a parser-and-changer. Agreed.

What about this simple solution:

Let "alter table rename column" parse the schema, search
for the column name. If it's in no constraint, etc, then do
the rename in the sqlite_master table.  If the column is
used anywhere, error out (which is not worse than before).
This will at least stop people from creating databases,
that can't be opened after mangling around in the
sqlite_master table.

As originally stated, my aim is not a full blown alter
table implementation right away, but only renaming
(possibly unreferenced) columns.


> Two alternatives: (a) actually write the
> parser-and-changer that processes SQL commands, or

For creating the actual changer, one might use the already
parsed in-memory-structure, change it, and dump it back out
as sql.  That might break formatting for people who love
it, but that's still lots better than doing nothing.  Being
able to dump the internal structures as sql might also be
helpful for debugging and writing test cases.


> (b) wait until the major file format changes in SQLite4,
> then change the way SQL stores the CREATE commands needed
> to construct a database so it stores a structured version
> of the commands instead of the raw text.

The "structured version" could be the dumped-sql from above?

But of course, sqlite4 could use some fancy structured
format for that as well. But why invent a new (binary)
format, when we have a text based format at hand, that can
do everything needed?


> The advantage of either change would be that it allows
> almost all the ALTER TABLE commands SQL users expect, not
> just changing column names.

If that's true, that would be great!


> This simplifies life not just for normal users but also
> for all the writers of SQLite GUI managers out there,

Simplifying the world for everyone would be awesome.

Like the foreignkeys are awesome.  Instead of everybody
having to create (possibly wrong) triggers, those triggers
are now builtin.


> who have to write nasty risky time-consuming hacks if
> they want to accomplish those operations.

I am especially afraid of the risky part. That's not the
reliable attribute sqlite is known for.
That's why my suggestion from above is to start with simple
operations, and if sqlite can't do them reliably (because
it would break something), then error out.
That would even improve the gui managers: They could try
the sqlite internal variant (reliable), then ask the user
"Okay, the reliable method did not work, I have some
fallback methods, which are not as reliable, but used to
work most of the time.  Should I apply those?"


> Simon.

Cheers

  Elrond
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Add support for new arch 'ppc64le' in "sqlite3" upstream package

2014-01-06 Thread ravi 

Hi,

We are in the process of adding support for new arch -ppc64le 
(powerpc 64-bit Little Endian) and I was looking at building "sqlite3" 
pacakge on ppc64le environment and we found that "sqlite3" package 
require a patch to config.guess and aclocal.m4 file.
Fortunatley , automake >=1.13.4 has all the needed bits to support 
building on ppc64le arch.


We want you to upgrade your automake in your build machine to >=1.13.4 
and spin-off a new version of "sqlite3" and let us know the new tar 
availability. So that we can test it on ppc64le architecture for you.


the release tarball that we picked is from 
"http://www.sqlite.org/2013/sqlite-autoconf-3080200.tar.gz;, which 
doesn'thave the ppc64le support.


Your response is highly appreciated.

--
Ravindran
IBM LinuxTechnologyCenter

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3session_changeset API oddity

2014-01-06 Thread Dan Kennedy 

On 01/06/2014 03:40 PM, Simon Slavin wrote:

On 6 Jan 2014, at 5:18am, Dan Kennedy  wrote:


sqlite3session_changeset() returns a blob containing the differences
between the current database and the database as it was when the
session object was first attached. After running "UNDO", there are
no differences. Hence the empty changeset.

Suppose, before I do the UNDO I make another changeset and do all the other 
things needed to make it start recording.  Will that end up with the invert of 
the first changeset ?


I think so, yes.

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3session_changeset API oddity

2014-01-06 Thread Simon Slavin 

On 6 Jan 2014, at 5:18am, Dan Kennedy  wrote:

> sqlite3session_changeset() returns a blob containing the differences
> between the current database and the database as it was when the
> session object was first attached. After running "UNDO", there are
> no differences. Hence the empty changeset.

Suppose, before I do the UNDO I make another changeset and do all the other 
things needed to make it start recording.  Will that end up with the invert of 
the first changeset ?

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users