Yes, any standard SQLite stored proc language is better than no
standard language, but Tcl is a hard sell because of [its {syntax}].
I used Tcl on a project several years ago and I still find
myself going back to the reference book every time I'm working with
arrays, loops and expressions. Also, Tcl is not well supported on
Cygwin and a few other non-mainstream platforms. It also seems
that the Tcl interpreter library is twice as large as SQLite itself,
but perhaps some micro-Tcl build option exists.
If you cannot have a PL/SQL or Transact-SQL style language, I'd
vote for making Lua the standard SQLite stored proc language.
Lua is the SQLite of embeddable scripting languages. The full
interpreter is only 150KB. It's very small and fast, has an active
user community and is extremely well supported on all sorts of odd
hardware and OSes.
Nothing is stopping anyone from creating such an extension except
for the fact that if it is not in the SQLite distro, it will never
be accepted as "the standard".
--- Dennis Cote <[EMAIL PROTECTED]> wrote:
> Joe Wilson wrote:
> > One of the strengths of SQLite is having the flexability to
> > hook it up to any language you like. But it would make life easier
> > for everyone if there was some sort of standard built-in simple
> > scripting language to create stored procedures and custom functions
> > within the standard SQLite distro to avoid exactly this sort of
> > compatability problem. Maybe some sort of simplififed PL/SQL or
> > Transact/SQL with the scripts autoloaded from an sqlite system table.
> > Or perhaps a standard SQLite convention to register a language with
> > it and have stored procs and functions of that language autoload
> > when the database is first attached. Anyone could easily write such
> > an extension, but having it as a standard in the distro is the key.
> >
> >
> Joe,
>
> I agree that having the ability to store procedures in the database
> itself would be a great addition to sqlite. And, it would have to be
> part of the standard distribution to be effective.
>
> I think that it is unlikely to happen for a couple of reasons.
>
> First, it would increase the size of the sqlite library and since many
> of Richard paying customers are very concerned about the library
> footprint, they would view this as a step backwards (but it could be
> done as a compile time option that they could leave out when building
> their minimalist versions).
>
> Second, I think Richard sees sqlite as a library that users should be
> using from a scripting language, in particular TCL, rather than a
> standalone database engine that should contain its own scripting
> environment. If we all switch to TCL, which is widely available for most
> platforms, then you can store your scripts in the database and execute
> them as needed. These scripts can also create user defined functions.
> There are more details on these ideas at
> http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
