On Wed, Jan 09, 2008 at 12:51:16PM +0000, [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 convenience of a single user.
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
nothing more, than "job of storage".
> > 2. It'll make my life easier. ;)
>
> But it makes my life harder. [..]
Probably a bit - but it was your own choice of such way of life, anyway. ;)
> > 3. It'll make the inserting operation faster, than using separate trim-s for
> > every value, at SQL level.
>
> No it won't. The string has to be trimmed either way. Doing
> it explicitly or magically in the background does not change the
> amount of work that has to be done. The work does not go away
> just because you cannot see it.
I don't know SQLite internals - but I was supposing, that trimming inserted
strings "by default", without looking at the SQL sequence first ("does there
exist a `trim' for current string? Yes, so we're stripping spaces..., or
perhaps not?"), should make that operation faster.
Perhaps I was wrong, not knowing, as I wrote, the internals.
> > 4. It can be, as I wrote, additional safety, f.e. if I forgot to set trim
> > anywhere in the application.
>
> It might also introduce bugs, if for some reason you ever decide
> that you really want a space at the beginning of some field.
But I'm ready to take the risk.
> > 5. In some simpler cases I could even omit entry check knowing, that strings
> > will be trimmed by SQLite anyway.
>
> See #2
...
> > 6. It's a feature "in the spirit" of the one, which allows to insert strings
> > containing single quotes, without a need to escape them first (very
> > convenient! :)
>
> You can easily write your own sqlite3_bind_trimmedtext() interface
> to accomplish this. The sqlite3_bind_trimmedtext() would first trim
> spaces from both ends of the input string, then pass the result
> through to sqlite3_bind_text(). No changes to the SQLite core are
> needed to accomplish this.
Thanks, perhaps it's a way for me to have this. Although, pay attention,
you just wrote, that "it's easy and doesn't need significant changes".
> > 7. It won't hurt anybody; as I wrote, it would be an option. But I'm pretty
> > sure, many can (and will) appreciate that. Never seen that in any other
> > database server (or engine).
>
> No, it would hurt others. Everybody that uses SQLite would have to
> pay the penalty of a larger executable and a more complicated code
> base. True, the change would be small and would not by itself be
> a big deal. But hundreds of such changes would quickly balloon the
> size of the SQLite library and make it so complex that we would no
> longer be able to maintain it effectively.
I fully agree. But my suggestion was about just one change (and very small,
as you agreed) - not about hundreds. Besides: (almost) every introduced
feature makes the code more complex. Should the development of the
applications be stopped then?
OK, as I wrote already, it was just a proposal. The others may suggest this
or that - so I made use out of my freedom to make the same.
--
pozdrawiam / regards
Zbigniew Baniewski
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
