<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 中。本节仅提供额外的信息。