On Mon, Dec 14, 2009 at 10:41:04AM +0100, Jean-Denis Muys scratched on the wall:
>
> On 12/13/09 16:34 , "Jay A. Kreibich" <j...@kreibi.ch> wrote:
>
> > On Sun, Dec 13, 2009 at 01:47:43PM +0300, Alexey Pechnikov scratched on the
> > wall:
>
> >> On Sunday 13 December 2009 02:09:48 Roger Binns wrote:
>
> >> The libsqlite is locale-independent but sqlite3 shell linked with
> >> readline and it's locale-dependent.
> >
> > That's a user choice. It does not link with readline by default.
> >
>
> The rest of this topic is way over my head, but I don't get this argument.
> Basically it seems to me it goes like that:
>
> Alexei: SQLite has a bug when use with optional feature X
> Jay: that's a user choice. Feature X is not on by default.
>
> So Jay, what you are saying is that SQLite doesn't have to provide bug-free
> features when those features are optional?
First of all, I personally don't consider this a "bug." It isn't
like the shell crashes, or corrupts data. The issue is that, when
utilizing an external library, some presets are not configured the
way the original poster desires.
From my viewpoint, if this is really truly "incorrect" or not is an
issue that is still open for debate. This gets into the question of
the intent and purpose of the application at hand. As others have
pointed out, the sqlite3 command line shell is designed to be fairly
light-weight and minimal. I'm not sure I'd go as far as saying it is
really just for debugging, but it is definitely not an sqlplus, or some
other massive "database administrator" shell environment that is
commonly seen with large RDBMS servers.
From that stance, the readline support is optional, not on by default,
and if you really don't like the way it works your best bet is to just
turn it off. Complaining about how readline support is completely broken
is most likely to simply get the whole feature marked "unsupported"--
or simply ripped out all together. No more bugs; problem solved.
But their high bar for supported features puts the SQLite developers
in a very difficult situation for anything a bit off the beaten path.
If a customer (and they do have paying customers, and they do get to
call some of the shots) wants an odd feature added to the shell or
one of the utility interfaces, there is the question of, "is this
officially supported?" And very often the answer is, "no."
And I think that is reasonable. The SQLite team is small, yet they
provide a great product that is constantly being updated. They take
testing of the core database engine very very seriously, and go to
great lengths to make sure the core library does what it is supposed
to do. I'd rather they spend time working on the core than adding
cute options to the shell. If I want to mess around with the shell,
I can do that. I'm not as adventurous to jump into the core library.
There are also other GUI tools and other products that allow me to
interact with the database library. If I really don't like the
shell, I can use one of those or write my own.
Also, consider this paragraph from the compile-options for SQLite:
The SQLITE_OMIT_* compile-time options are usually untested and
are almost certainly untested in combination. Any or all of these
options may be removed from the code in future releases and
without warning. For any particular release, some of these options
may cause compile-time or run-time failures, particularly when
used in combination with other options.
The team has been nice enough to try to provide these features.
They're very useful to some customers. But the team also knows they
can't test and support all these features as well as they should to
officially call them supported and correct. So they just admit--
these may work, they may not. If that makes you uncomfortable, don't
use them. If you need them, test them and possibly fix them yourself--
which is the exact same position you would be in if you had to develop
the feature yourself.
So, yes, I'm saying, and consider it acceptable, that the SQLite team
does not have to provide bug-free features when those features are
optional-- at least if they state the fact that the features are
optional and unsupported. That is, in effect, what "unsupported"
means.
Or "experimental." Virtual tables have been around some four years
and are still "experimental," despite the fact FTS3 (a rather
important feature) depends on them. I suspect the biggest reason
virtual tables are still marked experimental is that, being an
external interface, they're very very difficult to test.
The only place I think there is room for an argument is what,
exactly, is the status of the shell.c file and the sqlite3 tool. It
is clearly considered an important part of the SQLite distribution,
at least by customers, but it is not part of the core library and is
not as extensively tested. It might be fair to say the whole shell
is just a test example, but I can't find anything that actually says
much. If the whole shell is considered an unsupported utility, then
that is also clearly the case for any optional libraries it uses.
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Our opponent is an alien starship packed with atomic bombs. We have
a protractor." "I'll go home and see if I can scrounge up a ruler
and a piece of string." --from Anathem by Neal Stephenson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
