[sqlite] Re: "always-trim" - feature suggestion

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 03:35]: > I think, that it sometimes could be useful as secondary > protection: a feature (perhaps another "pragma"?), which will > cause stripping the spaces from beginning and end of every > inserted string.

Re: [sqlite] Re: "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 12:01:05PM +0100, Aristotle Pagaltzis wrote: > No, it doesn???t. And the next tiny feature like yours will not > cause a mess either. And the next one after that won???t cause a > mess either. Now keep addding tiny cannot-cause-a-mess features > for two years and the

[sqlite] configure script for amalgamation

Hi, Experimenting with distributing an autoconf configure script with the amalgamation package. So that it can do the usual "./configure && make install" installation. Prototype here: http://www.sqlite.org/sqlite-3.5.4-autoconf.tar.gz Could anybody who has time to try this out post if it

[sqlite] Re: "always-trim" - feature suggestion

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 12:15]: > Keep your flamewar just to yourself, will you? I’m sorry if that’s all you saw in my mail. Regards, -- Aristotle Pagaltzis // -

Re: [sqlite] "always-trim" - feature suggestion

Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: > > Why not have a possibility to make it default > behaviour of the SQL-engine itself, just by > using one "pragma"? > > 1. It'll make my code shorter. But it makes the SQLite core code larger. Why should the the SQLite core be enlarged for the

Re: [sqlite] Suppress auto index

"Yuvaraj Athur Raghuvir" <[EMAIL PROTECTED]> wrote: > Hello, > > When I upload data from a file into a table, I see that SQLite creates an > auto index table. Is it possible to instruct SQLite not to create any auto > indices for the tables I create? If so, how? > Any PRIMARY KEY (other than an

Re: [sqlite] Suppress auto index

On Wed, 9 Jan 2008 17:28:29 +0530, "Yuvaraj Athur Raghuvir" <[EMAIL PROTECTED]> wrote: >Hello, > >When I upload data from a file into a table, I see that >SQLite creates an auto index table. You didn't post your schema, so I have to guess a bit. I think you mean SQLite creates an index with

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: > > Why not have a possibility to make it default > > behaviour of the SQL-engine itself, just by > > using one "pragma"? > > > > 1. It'll make my code shorter. > > But it makes the SQLite core code larger. Why should the the >

Re: [sqlite] "always-trim" - feature suggestion

On Wed, 9 Jan 2008, Zbigniew Baniewski wrote: On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: Why not have a possibility to make it default behaviour of the SQL-engine itself, just by using one "pragma"? 1. It'll make my code shorter. But it makes the SQLite core code

[sqlite] Using sqlite3 from multiple threads

Hello, I like to use sqlite3 from a multi-threaded application. The situation is that I've several threads that like to write into a single DB file and into the same table. I read something about sqlite is thread save. But I'm not sure how much. Is it allowed to open the DB file and table

Re: [sqlite] "always-trim" - feature suggestion

On Wed, 9 Jan 2008 14:33:40 +0100, Zbigniew Baniewski <[EMAIL PROTECTED]> wrote: >On Wed, Jan 09, 2008 at 12:51:16PM +, [EMAIL PROTECTED] wrote: > >> > Why not have a possibility to make it default >> > behaviour of the SQL-engine itself, just by >> > using one "pragma"? >> > >> > 1. It'll

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote: > You know, I believe that an "embedded" SQL has a philosophy which is > inherently minimalist. ...yes, I know. > Your request specifically goes against the > philosophy of what SQLite was designed to be. DRH is working hard to >

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 08:57:18AM -0800, Ken wrote: > After reading your response to DRH, I think your being argumentative, > disrespectful and just plain rude. Thanks, I love you too. -- pozdrawiam / regards

Re: [sqlite] "always-trim" - feature suggestion

It's rather hard to say, if really just "single". SQLite, as I understood, has many users; just three of them were "against", until this time. Who knows, which of the existing features are used by how many users? Yesterday one of them wrote, that (if I properly understood) he appreciates

Re: [sqlite] Using sqlite3 from multiple threads

Andears, SQLITE 3.5.x is thread safe when configured and compiled with --enable-threadsafe. You can create multiple db connections to a single database. But only one connection will be allowed to write to the Database at a time. Take a look at http://www.sqlite.org/lockingv3.html

Re: [sqlite] Using sqlite3 from multiple threads

Am Wed, 9 Jan 2008 09:03:35 -0800 (PST) schrieb Ken: > Andears, > > SQLITE 3.5.x is thread safe when configured and compiled with > --enable-threadsafe. I've only 3.4.1 installed. But Gentoo has 3.5.4 in the unstable tree. I'll install that one if needed. And is it possible to find out at

RE: [sqlite] "always-trim" - feature suggestion

> -Original Message- > From: Zbigniew Baniewski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 11:08 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] "always-trim" - feature suggestion > > > On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote: > > > You know,

[sqlite] Sqlite File Access Restriction

Hi All, I am currently evaluating whether to move from bsddb to sqlite for our application’s data file format. Our application would provide file access like excel handles it, the first process to open the file gets full r/w, any other process that tries to open the file will either get

Re: [sqlite] configure script for amalgamation

Dan, Here are some results for you. AA == Autoconf Amalgamated. I did not run make install any any of the systems. But localized testing of sqlite3 seemed to work on all platforms. My configure flags ./configure --enable-threadsafe --disable-tcl --enable-tempstore All Platforms:

Re: [sqlite] "always-trim" - feature suggestion

On Wed, 9 Jan 2008 08:57:18 -0800 (PST), Ken <[EMAIL PROTECTED]> wrote: > I think your being argumentative, > disrespectful and just plain rude. I don't think Zbigniew does that on purpose. It's a culture thing. In Eastern Europe this is the normal way of reasoning, and isn't considered rude

Re: [sqlite] Using sqlite3 from multiple threads

Andreas Volz <[EMAIL PROTECTED]> wrote: > > I've only 3.4.1 installed. But Gentoo has 3.5.4 in the unstable tree. > I'll install that one if needed. > I see this idea expressed often, Andreas. Please help me to understand how I can improve the SQLite website or documentation to make it clear

Re: [sqlite] Using sqlite3 from multiple threads

Definately use 3.5.4. Not sure how to determine at compile time if the threadsafe part is enabled. You can always compile yourself to guarantee its set, thats what I do. sqlite will lock the database file for you automatically. Your threads do not need to implement locking. But they do need to

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 12:04:54PM -0600, Fred Williams wrote: > range beginning with MySQL and ending with Oracle. I do not beat a dead > horse trying to get the entire SQLite world and Dr. Hipp in particular > to "see it MY way." Give it up and look for a more feature rich DB and > leave us

Re: [sqlite] configure script for amalgamation

Ken <[EMAIL PROTECTED]> wrote: > > AIX had issues. See below. > sqlite3.c:35137: warning: case label value is less than minimum value for type Please see if check-in [4699] fixes this problem. http://www.sqlite.org/cvstrac/chngview?cn=4699 -- D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 07:15:52PM +0100, Kees Nuyt wrote: > It's a culture thing. In Eastern Europe this is the normal way > of reasoning, and isn't considered rude (my girlfriend is > Latvian from Russian parents, so I have some experience with > this kind of culture shock). I'm afraid, I

Re: [sqlite] "always-trim" - feature suggestion

fwiw, Zbigniew, I did not consider you rude or argumentative, but yes, this thread would have been "trimmed" a lot earlier after pretty much the very first "request for implementation." I hope you won't be put off by any perceived "hostility." No one wants to be that way. Your comments,

[sqlite] "Can't we all just get along?" [Was: RE: [sqlite] "always-trim" - feature suggestion]]

> -Original Message- > From: Zbigniew Baniewski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 10:57 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] "always-trim" - feature suggestion > > On Wed, Jan 09, 2008 at 07:15:52PM +0100, Kees Nuyt wrote: > > > It's a

Re: [sqlite] "always-trim" - feature suggestion

"P Kishor" <[EMAIL PROTECTED]> wrote: > fwiw, Zbigniew, I did not consider you rude or argumentative, but yes, > this thread would have been "trimmed" a lot earlier after pretty much > the very first "request for implementation." > > I hope you won't be put off by any perceived "hostility." No

Re: [sqlite] "Can't we all just get along?" [Was: RE: [sqlite] "always-trim" - feature suggestion]]

On Wed, Jan 09, 2008 at 11:12:42AM -0800, James Dennett wrote: > To take an example (and I apologize for it being from your message, but > that's a convenient place): when you write "I ended the discussion > *yesterday* already", it's easy for me to take that as being rude > because it implies

[sqlite] Unexpected side effect of update-buffering in fts3/2.

Actually, it makes perfect sense to me, but I wonder if the way it exposes internal implementation details needs to be addressed. Last spring, I made a change to fts2 to buffer updates within a transaction, and flush them at commit. This was a great performance improvement for the common case of

[sqlite] createAggregateFunction

hello all, I was wondering if it is possible to create an aggregate function that uses 3 parameters in PHP. I am able to create a function that uses 1 parameter, but when I add a second one, php runs out of memory. I know that this is probably not the place to post this, but just thought

[sqlite] Re: "Can't we all just get along?" [Was: Re: "always-trim" - feature suggestion]]

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 20:30]: > it wasn't my intention to offend anybody Neither was it mine, btw; my first mail on this thread was not a flame, nor was the mail I sent a few minutes ago (and I only sent that one because I had not seen this part of the thread yet).

Re: [sqlite] Re: "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 08:27:13PM +0100, Aristotle Pagaltzis wrote: > Yes, actually, almost all requested and many implemented features > are by definition bloat. It depends on definition, I guess... ;) -- pozdrawiam / regards

Re: [sqlite] Unexpected side effect of update-buffering in fts3/2.

"Scott Hess" <[EMAIL PROTECTED]> wrote: > > A partial fix for _this_ case is to surround the code in vdbeaux.c > which calls virtual-table xSync to preserve db->lastRowid across the > call. I say partial, because I think the code really would need to be > replicated to all virtual-table entry

[sqlite] Re: "always-trim" - feature suggestion

* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 18:15]: > On Wed, Jan 09, 2008 at 11:25:01AM -0500, Rob Sciuk wrote: > > and adding bloat will not contribute to its future success. > > Of course, any feature, which *you* aren't especially fond of, > you can describe as "bloat". Even the most

Re: [sqlite] createAggregateFunction

Nathan Biggs <[EMAIL PROTECTED]> wrote: > hello all, > > I was wondering if it is possible to create an aggregate function that > uses 3 parameters in PHP. I am able to create a function that uses 1 > parameter, but when I add a second one, php runs out of memory. I know > that this is

RE: [sqlite] Re: "Can't we all just get along?" [Was: Re: "always-trim" -feature suggestion]]

Never forget Hanlon's Razor: "Never attribute to malice that which can be adequately explained by stupidity." as flame-war retardant, this can be translated as: "Never attribute to malice what can be easily explained by difference of opinion." -or- "Don't hate the person, hate their opinion."

Re: [sqlite] "always-trim" - feature suggestion

On Wed, Jan 09, 2008 at 07:16:27PM +, [EMAIL PROTECTED] wrote: > Puneet also speaks for me on this matter. I'm glad, dr. Hipp, you haven't found my answer as offensive or abusive - of course, as I wrote, it was just a proposal, an idea - not any "demanding". But to know your opinion about

RE: [sqlite] Re: "always-trim" - feature suggestion

> -Original Message- > From: Aristotle Pagaltzis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 09, 2008 1:27 PM > To: sqlite-users@sqlite.org > Subject: [sqlite] Re: "always-trim" - feature suggestion > > > * Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-09 18:15]: > > On Wed,

Re: [sqlite] Using sqlite3 from multiple threads

[EMAIL PROTECTED] wrote: I see this idea expressed often, Andreas. Please help me to understand how I can improve the SQLite website or documentation to make it clear that SQLite does *not* need to be "installed"? I think the sqlite.org make this very clear, but people just can't believe

Re: [sqlite] Using sqlite3 from multiple threads

Am Wed, 09 Jan 2008 18:17:55 + schrieb [EMAIL PROTECTED]: > Andreas Volz <[EMAIL PROTECTED]> wrote: > > > > I've only 3.4.1 installed. But Gentoo has 3.5.4 in the unstable > > tree. I'll install that one if needed. > > > > I see this idea expressed often, Andreas. Please help me to >

Re: [sqlite] Unexpected side effect of update-buffering in fts3/2.

On Jan 9, 2008 11:55 AM, <[EMAIL PROTECTED]> wrote: > "Scott Hess" <[EMAIL PROTECTED]> wrote: > > A partial fix for _this_ case is to surround the code in vdbeaux.c > > which calls virtual-table xSync to preserve db->lastRowid across the > > call. I say partial, because I think the code really

Re: [sqlite] configure script for amalgamation

Dan and DRH, The amalgamated version as packaged in the link was really nice indeed. Much preferred over the full source code bundle I've been using to produce sqlite shared objects. Even nicer is the fact that the TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1 I not included as part of the

Re: [sqlite] Using sqlite3 from multiple threads

Andreas Volz <[EMAIL PROTECTED]> wrote: > > The reason is that I had some bad luck integrating applications into > Gentoo that include dependency sources. The Linux (here: Gentoo) way is > to have shared objects of all dependencies and the ability to let all > applications automatic benefit from

Re: [sqlite] configure script for amalgamation

Ken <[EMAIL PROTECTED]> wrote: > Dan and DRH, > > The amalgamated version as packaged in the link was really nice indeed. Much > preferred over the full source code bundle I've been using to produce sqlite > shared objects. > I take it that gcc -shared -o libsqlite3.so sqlite3.c

Re: [sqlite] configure script for amalgamation

That resolve the case lable warning... The following warning still remains: sqlite3.c: In function 'sqlite3RunVacuum': sqlite3.c:64923: warning: comparison is always true due to limited range of data type The code at that location is: #ifndef SQLITE_OMIT_AUTOVACUUM

Re: [sqlite] "always-trim" - feature suggestion

Some of the correspondents seem to have lost track of the meaning of "Open Source". They have the source code and can build their own version which trims, slashes or even burns. They certainly do not have to inflict their particular needs or preferences on the whole user community. I am

Re: [sqlite] Using sqlite3 from multiple threads

On Wed, Jan 09, 2008 at 09:03:51PM +, [EMAIL PROTECTED] wrote: > In fact, the only company > I know of that makes use of shared libraries for SQLite is Apple. Solaris will be shipping SQLite 3.x as a shared library. > They can get away with this because

Re: [sqlite] configure script for amalgamation

Dan and DRH, The amalgamated version as packaged in the link was really nice indeed. Much preferred over the full source code bundle I've been using to produce sqlite shared objects. Even nicer is the fact that the TCC += -DSQLITE_OMIT_LOAD_EXTENSION=1 Is not included as part of the

Re: [sqlite] Using sqlite3 from multiple threads

Am Wed, 9 Jan 2008 10:20:31 -0800 (PST) schrieb Ken: > Definately use 3.5.4. > > Not sure how to determine at compile time if the threadsafe part is > enabled. You can always compile yourself to guarantee its set, thats > what I do. > > sqlite will lock the database file for you automatically.

Re: [sqlite] Using sqlite3 from multiple threads

Nicolas Williams <[EMAIL PROTECTED]> wrote: > On Wed, Jan 09, 2008 at 09:03:51PM +, [EMAIL PROTECTED] wrote: > > In fact, the only company > > I know of that makes use of shared libraries for SQLite is Apple. > > Solaris will be shipping SQLite 3.x as a

Re: [sqlite] Using sqlite3 from multiple threads

Andreas Volz <[EMAIL PROTECTED]> wrote: > > I don't understand how to use the sqlite3_io_methods. It seems I need a > sqlite3_file. Not sure I get it from the API. The sqlite3_open call > returns an int. So how do I use this? > > Perhaps you could sketch some pseudo code or paste some code where

Re: [sqlite] Using sqlite3 from multiple threads

On Wed, Jan 09, 2008 at 10:06:30PM +, [EMAIL PROTECTED] wrote: > Nicolas Williams <[EMAIL PROTECTED]> wrote: > > Would you recommend that we not make SQLite 3.x in Solaris available to > > third parties? > > I think having a libsqlite3.so available is great. There will likely > be smaller

Re: [sqlite] configure script for amalgamation

I guess that would work, but I've always downloaded the full source. Ran configure with various options. Then compiled into libraries both 32 and 64bit. So a delivered amalgamated/autoconf is really really nice. Since, I'll no longer have to build from full source. Any to enable a

[sqlite] Optimized way of export/import of the sqlite database through C API Interface

Hi, I have an application that has to provide an export/import feature of the sqlite database. I have achieved the export through the normal "Select * >From TABLENAME" to export the database. I went through the C API Documentation reference but did not come across any such API. If there are APIs