> Good point, though personally I would weigh this in a different class of > backward compatibility changes.
I agree, but I have no evidence either way. You never really know what a customer is doing until you change something they were using. > I don't think changing this would be bad. > But I also don't think a change is necessary. > > Driving 51 in a zone posted 50 is also not in compliance (with a different > standard, of course). Yet we violate that standard all the time. > > The reality is that I'm not aware of a single platform that will fail to > generate correct code for this (outside of treat all warnings as errors). Again I agree, although again one never really knows. > Yes, it is a standards violation in the strictest sense. Yet it's not a big > deal given the number of successful deployments. > > If anyone can demonstrate an implementation that uses this identifier in a > way that is incompatible with SQLite, then it should be changed. Otherwise it > seems to me that disabling treat all warning as errors (or this one warning > in the impacted projects and files) is the least disruptive change for all > concerned. This is the core of this post, and the only part I disagree with. There are corporate environments in which extremely tight control is maintained over compliance and standards, and in which a decision as to how to treating various warnings and errors raised by various development tools involves multiple parties and multiple processes and multiple levels of approvals. It is simply not possible to form a blanket opinion on exactly how disruptive such a change would be in all possible users' environments; nor should one try. Regards David M Bennett FACS Andl - A New Database Language - andl.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
