On 9/2/21 17:39, Tom Spindler (moof) wrote:
In addition, the release notes for 3.36.0 say the deserialize option isLonger term, I think the right approach is to make base sqlite3 meet the sqlite3 default expectations. I remember us going around on this before (for json1, not rtree) and deciding we couldn't because it would be some kind of ABI break, and I'll try to find and read the archives.enabled by default, and it needs to be explicitly disabled. Anybody notice any problems in the interim? If not, I'd argue that's an OK argument against there being ABI breakage.
sqlite3 has two notions of enabled by default, and the one they really mean is configure. The build w/o configure is very sparse by default.
I'm not following what you are saying about ABI. As I see it these options cause SQL that would have failed to do what is expected and technically that's an ABI change, but not in any way we need to avoid.
I looked at the old discussion and didn't find the "we can't do this" I thought might have been there.
So if I commit adding a line to define RTREE, for example, in sqlite3 in current, does anybody object (would ask again on tech-userlevel)?
Same for other things where sqlite configure says it is default. And same questions for 9.