Re: [sqlite] Unrecognized "Z" UTC time zone signifier
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-02-21 13:45]: > Ralf Junker <[EMAIL PROTECTED]> wrote: > > SQLite does not recognize "Z" as the zero offset time zone > > specifier. > > If we start accepting any symbolic timezone names, seems like > we would then need to start accepting them all. Not hardly. FWIW, the IETF recommendation for timestamps in any new internet standards is to use the format specified in RFC 3339, which is based on codified experience. For time zones, it prescribes that they be given as either a numeric offset or `Z` a shortcut for `+00`; no provision is made for other symbolic names as those only cause trouble. So you should have no trouble refusing requests to support those. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Most widely deployed?
* Shawn Wilsher <[EMAIL PROTECTED]> [2008-02-21 20:00]: > > Every copy of Firefox 3 contains a copy of SQLite. > And Firefox 2 ;) Really? What is it used for? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Most widely deployed?
* Toby Roworth <[EMAIL PROTECTED]> [2008-02-20 14:35]: > I'm not sure if this was the right place to post this, but it > would be interesting to hear people's thoughts on the matter. I think the claim is unassailable. I have five different copies of the SQLite code on this computer alone, I think. Every Mac has several of them. One of the servers I deploy to has at least 10 copies of it. Every copy of Firefox 3 contains a copy of SQLite. Already the number of installations is astronomic; even so it is accelerating rapidly. The other libre databases cannot remotely keep up, much less the commercial ones. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] IE6 (was: Updatable views)
* P Kishor <[EMAIL PROTECTED]> [2008-02-12 03:20]: > One of the dangers of supporting "other standards" is that it > becomes hard to wean folks off of them when you do decide to go > "pure." > > Microsoft is experiencing a similar issue with IE. IE6 buggered > up the standards support royally, but enough people around the > world used it and made websites that were "compliant" with it > that when MS made IE7 which hewed to the standards much better, > all those websites broke. Well, this is completely off-topic, but to be precise, what MSFT did was not so much bugger up the standards support as never get around to implementing it. When IE6 was released, its standards support was on par with everyone else’s – better, in fact, in various areas. But the competition improved their browsers steadily, ensuring that the amount of breakage between two versions of any of their browsers would be small, whereas MSFT ignored the browser for some six years. *That* is how they buggered up. Anyway. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Mailing List Changes
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-02-05 02:35]: > The overwhelming majority of users prefer mailing list replies > to go back to the mailing list *only*. Reply-To munging is still harmful, because if the original sender had set this header, that information is lost; if someone really wants to send to mail to the sender instead of the list, after going through the contortions necessary, they will end up sending it to the sender’s From address, ie. the wrong one. So it goes. Rather, mailing list software should be setting Mail-Followup-To. Unfortunately there are a lot of broken clients out there which don’t have any clue about that one whatsoever. I believe the fine Microsoft products are among them, though I could be mistaken. So this Reply-To meddling persists. So it goes. Anyway, there are mail clients which largely work sanely despite adversity – read: mutt. Once told that a particular address is a mailing list, mutt will plainly ignore a munged Reply-To when doing a regular reply, offering instead a separate list-reply function which will send the reply to the list *only*, regardless of how the mailing list software is configured, and will also set Mail-Followup-To in the right circumstances. What mutt can’t do, of course, is recover the original value of a Reply-To header mangled by officious mailing list software. So it goes. (It’s kind of ludicrous, if you think about it, that most mail clients have not even the most basic dedicated support for mailing lists, nearly half a century after the birth of SMTP.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Re: Strange error "Incomplete SQL"
* Aristotle Pagaltzis <[EMAIL PROTECTED]> [2008-01-21 22:29]: > $ echo -e '\n;' >> error > $ sqlite < x > $ Err, the 2nd line is of course > $ sqlite < error Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Re: Strange error "Incomplete SQL"
* zak mc kracken <[EMAIL PROTECTED]> [2008-01-21 20:10]: > $ cat error > create table t(c); > select c from t; --COMMENT > $ sqlite < error > Incomplete SQL: select c from t; --COMMENT > $ sqlite -version > 2.8.17 > > if I remove the '--COMMENT' there is no error... why? > the problem persist using /*COMMENT*/ style $ echo -e '\n;' >> error $ sqlite < x $ The sqlite shell doesn’t parse SQL, it just looks for a semicolon as a statement terminator, so it sees your comment after it sees the SELECT statement, but doesn’t find a terminator after that. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[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). Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[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 useful feature > (which is useful FOR ME) - can be "bloat" for you. And vice > versa. No, I'm not using *all*available* features of SQLite. > Are they "bloat"? Answer yourself. Yes, actually, almost all requested and many implemented features are by definition bloat. Linus Torvalds once said that his most important job as the maintainer of the kernel is to say no to most suggested additions. I’m sure Dr. Hipp could give a list of things he would remove from SQLite if backward compatibility was not a concern. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[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 // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[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. http://sqlite.org/lang_createtrigger.html * Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 17:55]: > Yes: and from the perspective of the makers, perhaps this > doesn't have to look that bad: it's just using some C-function > to strip every string-value directly before insertion... I > don't expect, that this can cause a mess. 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 result *will* be a massive mess. http://blog.plover.com/prog/featurism.html Special-purpose features that do not help with anything else have no place in a library that is going to be used by hundreds of thousands of people. Some more on that by Mark Jason Dominus: It’s all right to be so short-sighted when you’re designing software for yourself, but when you design a language that will be used by thousands or millions of people, you have to have more economy. Every feature has a cost in implementation and maintenance and documentation and education, so the language designer has to make every feature count. If a feature isn’t widely useful to many people for many different kinds of tasks, it has negative value. In the limit, to accomplish all the things that people want from a language, unless most of your features are powerful and flexible, you have to include so very many of them that the language becomes an impossible morass. (Of course, there is another theory which states that this has already happened.) This came as no surprise to me. I maintain the Memoize module, which is fairly popular. People would frequently send me mail asking me to add a certain feature, such as timed expiration of cached data. I would reply that I didn’t want to do that, because it would slow down the module for everyone, and it would not help the next time I got a similar but slightly different request, such as a request for data that expires when it has been used a fixed number of times. The response was invariably along the lines of “But what would anyone want to do that for?” And then the following week I would get mail from someone else asking for expiration of data after it had been used a fixed number of times, and I would say that I didn’t want to put this in because it wouldn’t help people with the problem of timed expiration AND THE RESPONSE WOULD BE EXACTLY THE SAME. A module author must be good at foreseeing this sort of thing, and good at finding the best compromise solution for everyone’s problems, not just the butt-pimple of the week. A language designer must be even better at doing this, because many, many people will be stuck with the language for years. SQLite’s design doesn’t quite constitute a full-blown language, but it’s more demanding than a plain library. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Re: Trying to use SQLite3 with PHP5....
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-01-04 19:50]: > The Tool Control Language (TCL) is one of the most elegant and > power programming languages ever devised. TCL is not part of > the Algol family of languages (it is more closely related to > Lisp) which makes it difficult to grok for people who have only > been exposed to Algol-like langauges. But this does not detract > from the extreme elegance of the language. No, it doesn’t, but it also doesn’t change the fact that it’s kind of wretched. :-) It’s kind of a grown-up and much cleaner version of shell, which is likewise much-misunderstood. But personally I’d still not wish to write overly large codebases in it… though maybe it has become more suitable to this since the last time I looked, a long while ago at this point. I did enjoy the grammatic regularity then… shades of Forth (for which I retain a soft spot). > Let me state unambiguiously that SQLite would not be possible > were it not for TCL. I think that’s a bit of an overstatement. It seems that something like Lua (which admittedly has only lately really gotten into its own) would have been no less servicable. In principle any of the current crop of dynamic languages should suffice, though the major ones do not make it nearly as easy as Tcl to write bindings to C libraries. (I hear that Ruby is not half bad in this regard, though.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Re: EXISTS and NULLs
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-01-02 17:50]: > If you wanted to know if there were non-null entries you would > say: > >SELECT EXISTS(SELECT x FROM t1 WHERE x NOT NULL); In fact I usually say EXISTS ( SELECT NULL FROM ... ) in order to emphasize that the row data is of no interest in the subquery in question. > Can somebody please confirm that this is the correct behavior > and that EXISTS does not do any special treatment of NULL > values? I have seen the above EXISTS SELECT NULL in several books, with the collective implication that this construct must work in MySQL, Postgres, Oracle, DB2, SQL Server and Sybase. It’s a safe bet that SQLite works as expected. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> - To unsubscribe, send email to [EMAIL PROTECTED] -
