On Mon, Jan 10, 2011 at 9:00 PM, Igor Tandetnik <itandet...@mvps.org> wrote: ... They are stuck calling sqlite3_step - incorrectly - so the only remaining move is to modify the behavior of sqlite3_step itself, to allow them to muddle through. ...
Understood and concurred. It makes sense to capitulate and have the current implementation of sqlite3_step() support how the market has decided to use it. *Right, wrong, or otherwise, it is what it is.* However for new dev efforts, does it not make sense to consider deploying sqlite3_step_v2() which functions as the devs intend - i.e. leave sqlite3_step() in place for the legacy code and made sqlite3_step_v2() the new defacto standard for current/future dev efforts.?. -t On Mon, Jan 10, 2011 at 9:00 PM, Igor Tandetnik <itandet...@mvps.org> wrote: > On 1/10/2011 8:52 PM, Chris Peachment wrote: > > On Mon, 2011-01-10 at 19:54 -0500, Richard Hipp wrote: > > > > <snip> > > > >> This is, technically, a compatibility break. On the other hand, there > >> appear to be vast numbers of smartphone applications that currently > depend > >> on undefined behavior and will suddenly stop working if we don't make > this > >> change. > >> > > > > What's wrong with using a new function: sqlite3_step_v2() > > Presumably, it would be just as difficult to get those broken apps to > switch to sqlite3_step_v2 as it would be to get them fixed in the first > place. They are stuck calling sqlite3_step - incorrectly - so the only > remaining move is to modify the behavior of sqlite3_step itself, to > allow them to muddle through. > -- > Igor Tandetnik > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
