Re: [sqlite] sqlite3session_changeset API oddity

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.

Re: [sqlite] sqlite3session_changeset API oddity

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

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

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

Re: [sqlite] RFE: Rename Column

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

[sqlite] Generating sqlite4.c

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

Re: [sqlite] "Common Table Expression"

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

[sqlite] Sqlite as a platform performance comparison tool

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

Re: [sqlite] RFE: Rename Column

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

Re: [sqlite] RFE: Rename 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

[sqlite] Personal function and parameter evaluation.

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

Re: [sqlite] Personal function and parameter evaluation.

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

Re: [sqlite] "Common Table Expression"

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

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

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

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

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

Re: [sqlite] Personal function and parameter evaluation.

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 ) >> { >> // >>

Re: [sqlite] Personal function and parameter evaluation.

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

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

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