Merge it now. As stated in documentation: "The SQLite documentation clearly states that, if there is no AS clause, the names of output columns are indeterminate, arbitrary, and subject to change." It would be my hope that legacy applications exploiting the returned column name given said documentation would be compiling a specific version of the code, or providing a specific dll to accompany the app. The legacy apps should not have a problem, in those scenarios.
Moving forward, wanting to implement the latest SQLite, the change has been clearly documented. And so, testing will be required to upgrade. IMO, dvn On Mon, Jul 31, 2017 at 10:30 AM, Neville Dastur <[email protected]> wrote: > IMHO the inconsistency is a bug of sorts and so would “vote” for a merge > now. > In a sense applications that risk breaking are due to hacking around what > is documented. And if the change is going to happen it might as well be now > along with the major versions change. > > -- > L: http://uk.linkedin.com/in/nevilledastur <http://uk.linkedin.com/in/ > nevilledastur> > T: @nevilledastur <https://twitter.com/nevilledastur> > Clinical Software Solutions: http://www.clinsoftsolutions.com < > http://www.clinsoftsolutions.com/> > hospify.com <http://hospify.com/> - secure healthcare communication > > > > > On 31 Jul 2017, at 16:21, Richard Hipp <[email protected]> wrote: > > > > Ticket https://sqlite.org/src/info/de3403bf5ae5f72ed describes a > > problem with column naming, and a proposed solution. Today's > > question: Should the proposed solution be merged into the 3.20.0 > > release? > > > > Pros: (1) The change makes column names more consistent. (2) The > > change fixes some breakage caused by a query planner enhancement > > introduced in 3.19.0. (3) The change makes column naming in SQLite > > work (more) like it does in PostgreSQL, MySQL, and SQLServer. (4) The > > change will likely be in 3.21.0 even it it isn't in 3.20.0. Better to > > go ahead and get over the pain of any breakage that results now, > > rather than putting it off until later. > > > > Cons: (5) The change might cause breakage for legacy applications that > > depend on the older (arguably buggy) behavior. (6) This seems like a > > big change to receive so little beta exposure prior to the official > > release. (7) Making the merge will (or should) delay the release by a > > day or so. The release was going to happen tomorrow (2017-08-01) but > > if we do the merge, I think the release should be postponed until > > 2017-08-02 or 2017-08-03. > > > > Let me know your thoughts. Replies to the mailing list are > > preferred, but private email directly to me is also accepted. > > -- > > D. Richard Hipp > > [email protected] > > _______________________________________________ > > sqlite-users mailing list > > [email protected] > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
