Zbigniew Baniewski <[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. > 2. It'll make my life easier. ;) But it makes my life harder. Not only do I have to develop a patch to the core to implement the requested feature, but I also have to develop test scripts to verify its correct operation, and I have to support and maintain this feature forever into the future. > 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. > 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. > 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. > 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. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
