[sqlite] Downside of setting SQLITE_MAX_ATTACHED to 125

Hello everyone! After consulting the manual and doing a little googling I'm still unsure about the runtime cost of a high SQLITE_MAX_ATTACHED setting. I admit 10 is a reasonable default, but it's possible that I'll need a bit more. Can I just set it to 125 right away and stop worrying about it,

Re: [sqlite] Bug?: unexpected behaviour - alter parent table in a deferred foreign key relationship

of them in production until the situation is resolved. Do you have any suggestion how I should go about it? Can I escalate this to someone? Thanks in advance, Máté szmate1618 ezt írta (időpont: 2018. nov. 23., P, 17:21): > >"PRAGMA foreign_keys = ?" is a property of the

Re: [sqlite] Bug?: unexpected behaviour - alter parent table in a deferred foreign key relationship

or just do a backup of the database file before 'risky' transactions, but it would be much easier if I could just use deferred foreign keys that don't let me commit if the database is in an inconsistent state. Máté Dan Kennedy ezt írta (időpont: 2018. nov. 23., P, 16:30): > On 11/23/2018 09:5

[sqlite] Bug?: unexpected behaviour - alter parent table in a deferred foreign key relationship

Dear list members, I have the following problem, with which I'd like to request your aid: Currently, at version 3.25.2, SQLite only has a limited support for alter table. E.g. you cannot change the datatype (type affinity) of a column, or drop a column. The usual workaround is to create a new

[sqlite] Bug: float granularity breaking unique contraint?

Dear SQLite people, Please bless me with your infinite wisdom. I'm using SQLite 3.25.2 on Windows, downloaded the latest precompiled binaries from the official page https://sqlite.org/download.htmlExecuting the following code DROP TABLE IF EXISTS TestReal;CREATE TABLE TestReal(A REAL