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] -----------------------------------------------------------------------------