[Bug] SQL commands can modify persistent tables shadowed by temporary objects #1372

Search before asking

• I searched in the issues and found nothing similar.

Please describe the bug 🐞

When a temporary table or view shadows a persistent Paimon table, SELECT resolves to the temporary object, but some SQL commands can still modify the underlying persistent table.

The affected commands include ALTER TABLE (including ADD PARTITION, DROP PARTITION, and schema changes), INSERT OVERWRITE ... PARTITION, MSCK REPAIR TABLE, and ANALYZE TABLE. The reproduction below shows how DROP PARTITION deletes data from the hidden persistent table.

Reproduction

Run the setup on a fresh table for each case.

CREATE TABLE paimon.default.events (id INT, pt INT) PARTITIONED BY (pt);
INSERT INTO paimon.default.events VALUES (1, 1), (2, 2);

CREATE TEMPORARY VIEW paimon.default.events AS SELECT 99 AS id;
SELECT id FROM paimon.default.events; -- Returns 99 from the temporary view.

Run one of these commands while the temporary view exists.

ALTER TABLE paimon.default.events DROP PARTITION (pt = 1);

INSERT OVERWRITE paimon.default.events PARTITION (pt = 1) SELECT 8;

Remove the temporary view and inspect the persistent table.

DROP TEMPORARY VIEW paimon.default.events;
SELECT id, pt FROM paimon.default.events ORDER BY id;

• Expected — Both commands reject the temporary target. The persistent table still contains (1, 1) and (2, 2).
• Actual — DROP PARTITION succeeds and leaves only (2, 2). In a separate run, INSERT OVERWRITE succeeds and replaces (1, 1) with (8, 1).

Solution

Reuse the existing temporary-object lookup to reject these commands before they modify the persistent table's data, partition registrations, or statistics.

Are you willing to submit a PR?

• I'm willing to submit a PR!