The "load_extension()" has been ignored.

[LLMTesting-Ojiken]

----------------------------------------DB State And Empty View 1 Create ---------------------------------

CREATE TABLE rt0
(
c0 INTEGER,
c1 INTEGER,
c2 INTEGER
);
INSERT INTO rt0 (c0, c1, c2)
VALUES (0, 0, 0);

CREATE VIRTUAL TABLE vt1 USING fts4
(
c0,
c1
UNINDEXED,
c2
UNINDEXED,
languageid=
"lid"
);

CREATE VIEW v0 AS
SELECT 1 AS c0
WHERE 0;
SELECT *
FROM v0;
------------------------------------------------End-------------------------------------------------

SELECT COALESCE(SUM(1), 0)
FROM rt0,
v0
WHERE load_extension(1);

Result: 0 (The error occurred when loading the extension (1), but it was not triggered. I suspect this is because v0 is an empty view, so the WHERE clause was optimized)

----------------------------------------Empty View Create 2----------------------------------------
DROP VIEW IF EXISTS v0;
CREATE VIEW v0(c0) AS
SELECT ((((vt1.c0) OR (vt1.c1))) AND (vt1.c1)) COLLATE BINARY
FROM vt1,
rt0
WHERE (vt1.c1)
ORDER BY vt1.c1 NULLS FIRST, ((vt1.c0) NOT NULL) NULLS LAST, CASE WHEN (((rt0.c1, vt1.c0, rt0.c0, vt1.c2, vt1.c0)) NOT BETWEEN ((rt0.c2, 0.10535671390266399, vt1.c0, vt1.c2, vt1.c1)) AND ((rt0.c0, vt1.c2, NULL, rt0.c1, rt0.c1))) THEN UPPER(vt1.c0) END;
------------------------------------------------End-------------------------------------------------

SELECT COALESCE(SUM(1), 0)
FROM rt0,
v0
WHERE load_extension(1);

Result: Error (v0 used a more complex creation method to create it, but it is still an empty view, and the error was triggered)

[LLMTesting-Ojiken]

I established a control group:

SELECT COALESCE(SUM(1), 0)
FROM rt0,
v0
WHERE abs(1,2);

This sentence will normally trigger an error both before and after the change in the way the "empty view" is created.

[gotson]

you need to follow the issue template and provide enough information to understand what this is about.

[LLMTesting-Ojiken]

Describe the bug
load_extension() in SQLite3 is not required to always trigger an error—it is just used here as a side-effect probe to observe the planner’s execution path.

For two logically equivalent environments (for example, two empty views Cartesian-joined with a table), adding a side-effect expression s = load_extension(1) can produce inconsistent behavior.

More formally, let env1() and env2() be two equivalent environments (same SELECT, FROM parts producing empty relations).

In theory, we would expect:

env1(s) ≡ env2(s)

That is, they should behave consistently: either both trigger an error or both do not.

The observed difference arises because the planner treats “statically provable empty” and “runtime empty” subqueries differently, which leads to different execution paths for the side-effect.

I think this difference, while not a bug per se, highlights an inconsistency in planner behavior for logically equivalent empty queries.

To Reproduce
1.Case A: Simple empty view
CREATE TABLE rt0
(
c0 INTEGER,
c1 INTEGER,
c2 INTEGER
);
INSERT INTO rt0 (c0, c1, c2)
VALUES (0, 0, 0);

CREATE VIRTUAL TABLE vt1 USING fts4
(
c0,
c1
UNINDEXED,
c2
UNINDEXED,
languageid=
"lid"
);

CREATE VIEW v0 AS
SELECT 1 AS c0
WHERE 0;
SELECT *
FROM v0;

SELECT COALESCE(SUM(1), 0)
FROM rt0,
v0
WHERE load_extension(1);

Actual result: 0 or error.
Observation: The error occurred.

2.Case B：complex statement

Change the generation method of v0:

DROP VIEW IF EXISTS v0;
CREATE VIEW v0(c0) AS
SELECT ((((vt1.c0) OR (vt1.c1))) AND (vt1.c1)) COLLATE BINARY
FROM vt1,
rt0
WHERE (vt1.c1)
ORDER BY vt1.c1 NULLS FIRST, ((vt1.c0) NOT NULL) NULLS LAST, CASE WHEN (((rt0.c1, vt1.c0, rt0.c0, vt1.c2, vt1.c0)) NOT BETWEEN ((rt0.c2, 0.10535671390266399, vt1.c0, vt1.c2, vt1.c1)) AND ((rt0.c0, vt1.c2, NULL, rt0.c1, rt0.c1))) THEN UPPER(vt1.c0) END;

SELECT COALESCE(SUM(1), 0)
FROM rt0,
v0
WHERE load_extension(1);

Actual result: [SQLITE_ERROR] SQL error or missing database (not authorized)。
Observation: v0 used a more complex creation method to create it, but it is still an empty view, and the error was triggered.

Expected behavior
For the following query:
SELECT COALESCE(SUM(1), 0)
FROM rt0, v0
WHERE load_extension(1);

the expected behavior should be consistent and satisfy at least one of the following:
Consistent execution: regardless of how v0 is defined, if the query includes WHERE load_extension(1), it should be evaluated and raise the corresponding error;
Consistent non-execution: if optimization allows the WHERE clause to be skipped in some cases, the same behavior should apply consistently across logically equivalent empty view scenarios.
However, the current behavior differs between Case A and Case B.

Logs
None

Environment
macOS Sequoia 15.6.1
Apple M1 Pro
sqlite-jdbc version 3.51.1.1

[gotson]

does it happen on SQLite CLI ?

[LLMTesting-Ojiken]

SQLite CLI (I assume you mean SQLite3 Fiddle) will display that the function "load_extension" does not exist and report an error.
This phenomenon has been replicated for me in the sqlite-jdbc jar package when used in database management tools (such as Datagrip) and development tools (IntelliJ IDEA).

[gotson]

I still don't quite understand how this relates to any existing issue in the real world. It seems that the issue reported (as well as the other ones you reported) are not about real world use cases, but more like exploratory testing or something.