<RFC 标题>

• RFC PR: datafuselabs/databend#0000
• Tracking Issue: datafuselabs/databend#0000

摘要

对提案的单段解释。

动机

我们为什么要这样做？它支持哪些用例？预期的结果是什么？

指导性解释

解释该提案，就好像它已经包含在 databend 中，并且你正在向其他 databend 用户教授它一样。这通常意味着：

• 介绍新的命名概念。
• 主要通过示例解释该功能。
• 解释 databend 用户应该如何_思考_该功能，以及它应该如何影响他们使用 databend 的方式。它应该尽可能具体地解释影响。
• 如果适用，提供示例错误消息、弃用警告或迁移指南。
• 如果适用，描述向现有 databend 用户和新的 databend 用户教授此功能的区别。

参考性解释

这是 RFC 的技术部分。足够详细地解释设计，以便：

• 它与其他功能的交互清晰。
• 如何实现该功能是相当清楚的。
• 通过示例剖析了边界情况。

本节应返回到上一节中给出的示例，并更全面地解释详细的提案如何使这些示例起作用。

缺点

我们为什么_不_应该这样做？

基本原理和替代方案

• 为什么这种设计是可能的设计空间中最好的？
• 已经考虑了哪些其他设计，以及不选择它们的基本原理是什么？
• 不这样做的影响是什么？

先有技术

讨论与本提案相关的现有技术，包括好的和坏的。 以下是一些可以包括的示例：

• 我们可以从其他社区在这里所做的事情中学到什么教训？

本节旨在鼓励你作为作者思考其他社区的经验教训，并为你的 RFC 阅读者提供更全面的了解。 如果没有先前的技术，那也没关系 - 你的想法对我们来说很有趣，无论它们是全新的还是来自其他项目的改编。

未解决的问题

• 在此合并之前，你希望通过 RFC 流程解决设计的哪些部分？
• 你认为哪些相关问题超出了此 RFC 的范围，可以在将来独立于此 RFC 的解决方案来解决？

未来可能性

考虑一下你的提案的自然扩展和演变会是什么，以及它将如何影响 databend。尝试使用本节作为工具，更全面地考虑你的提案与项目的所有可能交互。

此外，还要考虑这一切如何融入项目的路线图。

这也是一个“转储想法”的好地方，如果它们超出了 你正在编写的 RFC 的范围，但在其他方面相关。

如果你已经尝试过但无法想到任何未来的可能性， 你可以声明你无法想到任何事情。

请注意，在未来可能性部分写下任何内容 都不是接受当前或未来 RFC 的理由；此类注释应 位于本 RFC 或后续 RFC 的动机或基本原理部分。 本节仅提供其他信息。