Ibis项目中DuckDB后端临时表创建问题分析

在Ibis项目中使用DuckDB后端时，开发者可能会遇到一个关于临时表创建路径的典型问题。本文将深入分析该问题的成因、影响范围以及解决方案。

问题现象

当用户通过Ibis连接到DuckDB并尝试缓存表数据时，系统会抛出CatalogException异常，提示"Schema with name public does not exist!"。这种情况通常发生在以下两种场景中：

1. 当连接到PostgreSQL数据库并通过DuckDB的Postgres扩展访问数据时
2. 当在DuckDB中创建并使用非默认schema时

技术背景

DuckDB采用三级命名空间结构：catalog.schema.table。对于临时表，DuckDB有特殊处理机制：

• 所有临时表必须创建在temp catalog下
• DuckDB文档明确指出临时表应位于temp.main schema中
• 这是DuckDB保证始终存在的标准路径

问题根源

当前Ibis实现中存在以下关键问题：

1. 路径选择逻辑：系统错误地尝试在temp catalog下复制原始表的schema路径
2. 硬编码依赖：默认使用temp catalog但未强制使用main schema
3. 跨数据库限制：尝试通过DuckDB创建PostgreSQL临时表时遇到上游限制

影响分析

该问题会导致：

• 在非默认schema环境下缓存操作失败
• 跨数据库连接场景下的功能受限
• 开发者体验下降，需要手动处理路径问题

解决方案

正确的实现应该：

1. 强制所有临时表创建在temp.main路径下
2. 忽略原始表的schema信息，统一使用标准路径
3. 对于跨数据库场景，明确功能限制并提供友好提示

技术建议

对于需要在PostgreSQL中创建临时表的场景，建议：

1. 直接通过PostgreSQL连接创建临时表
2. 考虑使用物化视图替代临时表
3. 等待DuckDB上游对Postgres扩展的改进

总结

这个问题揭示了数据库抽象层在处理不同后端特性时的挑战。通过强制标准化临时表路径，可以确保DuckDB后端在各种使用场景下的稳定性。同时，这也提醒我们在设计跨数据库系统时需要考虑各后端的特殊限制和最佳实践。