ST_前缀是否适合SQL / MM第3部分中未包含的功能？

我在这个Github问题中正在阅读有关Presto地理空间扩展的主题，其中line_locate_point引入了函数。它基于PostGIS的ST_LineLocatePoint功能，该功能返回一个浮点数，该浮点数表示沿该点上到给定位置的最近点的线的分数。

提出了一个问题，为什么命名它line_locate_point而不是ST_LineLocatePointPostGIS版本。响应是此功能在SQL / MM Part 3标准中不存在，因此不应以开头ST_。

快速阅读标准，对于如何处理将空间功能引入标准以外的数据库的情况，我没有任何意见。是的精神ST_前缀区分空间的功能从非空间功能（如似乎是在PostGIS的情况下），或者是它表明，在SQL / MM第3部分同等功能的函数符合规定？

纵观Presto API的当前状态，我不得不说，后一种方法看起来不太干净，并且在名称为何不一致方面引入了一些困惑，但是也许可以通过顶部的简单注释解决。

那么，我的问题是，我是否忽略了该标准的某些方面，以允许将其扩展到已定义的空间对象之外，或者是否遵循以下标准的某些书面或非书面规则明确禁止这样做。

— 布莱多
source

我认为这是一个公平的问题，但从本质上讲可以归结为见解。我希望所有明显具有空间性的功能，即它们在矢量，栅格，拓扑，3D曲面等上运行时都使用前缀ST_。我从来没有想过要根据它是否在规范中来问这是否合适。尽管互操作性很重要并且很理想，但我当然不希望仅通过执行SQL / MM规范中的函数来阻止Postgis。而且我认为使用其他一些前缀会引起很多混乱。

— 约翰·鲍威尔，

我不明白为什么我的问题只是因为“基于观点”而被搁置了。我的问题是明确它是否是基于舆论，或者如果我俯瞰，该标准的某些方面做出该决定基于事实的。

— 布莱道

抱歉，我刚刚重新阅读了您的问题，并且确实存在一个明确的，非基于观点的问题。我的2c是，如果它是明确空间的，则无论它是否在标准中，它都将获得ST_。我已重新表决。

— 约翰·鲍威尔

在我看来，这是基于意见的。如果开发人员愿意，SQL / MM标准不能拒绝开发人员创建自己的带有ST_前缀的函数，甚至是非空间函数。但是，开发人员可能会以其他方式拒绝这样做。作为比较，SpatiaLite具有许多具有ST_同义词的空间但非SQL / MM函数，而另一些则没有gaia-gis.it/gaia-sins/spatialite-sql-latest.html。

— user30184 '18

我问的不是SQL / MM是否可以强迫开发人员做某事。我在问标准本身的建议。该标准长达1500页，我没有阅读其中的每一行，所以我要问这里的社区-一些人帮助编写该标准和相关标准-建议什么，或者它是否会使这些决定推迟另一个标准或明确选择不解决此问题。这些是基于事实的请求。

— 布莱道

该OpenSpatial规范说这个东西很多，

在将此SQL与SQL / MM的SQL集成时，ST_应适当使用类型名称前缀“ ”。

和，

SQL / MM中的类名称带有“ ST_”前缀。这是可选的，实现可以选择删除此前缀，就像在本标准中的不同地方所做的那样。

本委员会的草案ISO / IEC CD13249-3第5版

ISO / IEC 13249的此部分将前缀ST_用于用户定义的类型，属性，SQL调用的例程表和视图名称。ISO / IEC 13249的此部分使用前缀“ ST_Private”表示某些属性的名称。使用' ST_Private'表示该属性不适用于公共用途。

这就是我们所拥有的，

SQL / MM建议使用前缀。
SQL / MM说前缀是可选的。
ISO也使用ST_前缀。

我会这样说

ST_应该将的使用视为最终用户的非保留关键字。确实没有理由使用此前缀来使最终用户功能。您最好只使用STx_。我们知道至少有两个带有此前缀建议的机构（OpenSpatial）SQL / MM和ISO。另外，许多RDBMS带有该前缀的污染符号。

历史可能还有更多，但我找不到关于此的更多当代信息。

— 埃文·卡洛尔
source