tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sqlite3 extensions again

On 9/2/21 17:39, Tom Spindler (moof) wrote:
Longer 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.
In addition, the release notes for 3.36.0 say the deserialize option is
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.

Home | Main Index | Thread Index | Old Index