ST_プレフィックスは、SQL / MMパート3に含まれていない関数に適していますか？

このGithubの問題でPrestoの地理空間拡張に関するスレッドを読んでいたところ、関数line_locate_pointが導入されました。これはPostGISのST_LineLocatePoint関数に基づいており、特定の場所に最も近いポイントのラインに沿った分数を表すフロートを返します。

PostGISバージョンとは異なりline_locate_point、なぜ名前が付けられたのかという疑問が持ち上がりましたST_LineLocatePoint。応答は、この関数はSQL / MMパート3標準に存在しないため、で始まるべきではないというものでしたST_。

標準をすばやく読んで、標準にない空間関数をデータベースに導入する場合の処理​​方法についてのコメントはありません。ST_接頭辞の精神は、空間関数を非空間関数と区別するためですか（PostGISの場合のように）、または関数がSQL / MMパート3の同等の関数に準拠していることを示すためですか？

PrestoのAPIの現在の状態を見ると、後者のアプローチはあまりきれいに見えず、名前が一貫していない理由について混乱を招いていると言わざるを得ませんが、おそらくこれは上部の簡単なメモで対処できます。

私の質問は、定義された空間オブジェクトのセットを超えて拡張できるように見落としている標準の側面があるかどうか、または以下の標準の書かれたまたは書かれていない規則によって明示的に禁止されている場合。

OpenSpatial仕様では、このことについて、多くの事を言います

このSQLをSQL / MMのSQLと統合する場合、タイプ名プレフィックス「ST_」を適切に使用する必要があります。

そして、

SQL / MMのクラス名には「ST_」プレフィックスが付きます。これはオプションであり、実装は、この標準のさまざまな場所で行われているように、このプレフィックスを削除することを選択できます。

この委員会の草案からISO / IEC CD13249-3 ed 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で公開された少なくとも2つの機関を知っています。さらに、多くのRDBMSがその接頭辞を持つシンボルを汚染します。

歴史にはもっとあるかもしれませんが、これに関する現代的な情報はこれ以上見つかりません。