Подходит ли префикс ST_ для функций, не включенных в SQL / MM Part 3?

12

Я читал тему о геопространственном расширении для Presto в этом выпуске Github , где была представлена ​​функция line_locate_point. Он основан на ST_LineLocatePointфункции PostGIS , которая возвращает число с плавающей запятой, представляющее дробь вдоль линии ближайшей точки на этой линии в заданном месте.

Был задан вопрос, почему он был назван, line_locate_pointа не ST_LineLocatePointкак версия PostGIS. Ответ был таков: эта функция не существует в стандарте SQL / MM Part 3 и поэтому не должна начинаться с ST_.

Быстро читая стандарт, я не вижу никаких комментариев о том, как обрабатывать случаи, когда вы вводите пространственную функцию в вашу базу данных, которая не входит в стандарт. Является ли смысл ST_префикса отличать пространственные функции от непространственных функций (как это имеет место в PostGIS), или это указывает на то, что функция соответствует эквивалентной функции в SQL / MM Part 3?

Глядя на текущее состояние API Presto , я должен сказать, что последний подход выглядит менее чистым и вносит некоторую путаницу в вопрос о том, почему имена не согласованы, но, возможно, это можно решить с помощью простой заметки вверху.

Мой вопрос, таким образом, заключается в том, есть ли какой-то аспект стандарта, который я пропускаю, который позволяет расширить его за пределы определенного набора пространственных объектов, или, в качестве альтернативы, если это прямо запрещено каким-либо письменным или неписаным правилом следования стандартам ,

postgis sql spatial-database standards Brideau
источник
Я думаю, что это справедливый вопрос, но, по сути, сводится к вопросу мнения. Я ожидаю, что все функции, которые являются явно пространственными, то есть они работают с вектором, растром, топологией, трехмерной поверхностью и т. Д., Принимают префикс ST_. Мне никогда не приходило в голову спросить, было ли это подходящим использованием, основываясь на том, было ли это в спецификации или нет. Хотя совместимость важна и желательна, я, конечно, не хотел бы, чтобы Postgis сдерживался только реализацией функций в спецификации SQL / MM. И я думаю, что использование какого-то другого префикса вызовет много путаницы.
Джон Пауэлл
Я не понимаю, почему мой вопрос был отложен из-за того, что он «основан на мнении». Мой вопрос явно о том, основано ли это на мнениях, или есть какой-то аспект стандарта, который я пропускаю, который делает это решение основанным на фактах.
Brideau
Извинения, я только что перечитал ваш вопрос, и там действительно есть четкий, не основанный на мнениях вопрос. Мой 2c заключается в том, что, если он явно пространственный, он получает ST_, независимо от того, находится он в стандартах или нет. Я проголосовал заново.
Джон Пауэлл,
На мой взгляд, это основано на мнении. Стандарт SQL / MM не может запретить разработчикам создавать свои собственные функции с префиксом ST_, если они хотят, даже непространственные функции. Однако разработчики могут решить сделать это по-другому. В качестве сравнения, SpatiaLite имеет много пространственных, но не-SQL / MM функций, которые имеют синонимы ST_, некоторые другие, которые не имеют gaia-gis.it/gaia-sins/spatialite-sql-latest.html .
user30184
Вопрос о том, может ли SQL / MM заставить или не может заставить разработчика что-то делать, - это не тот вопрос, который я задаю. Я спрашиваю о том, что рекомендует сам стандарт. Стандарт имеет длину 1500 страниц, и я не прочитал каждую его строку, поэтому я спрашиваю сообщество - некоторые из которых помогают написать его и соответствующие стандарты - что рекомендуется, или, возможно, откладывает ли это принятие решений на другой стандарт или явно решили не заниматься этим. Это основанные на фактах запросы.
Brideau

Ответы:

1

Спецификация OpenSpatial говорит об этом много вещей,

При интеграции этого SQL с SQL / MM префикс имени типа " ST_" должен использоваться соответствующим образом.

И,

Имена классов в SQL / MM имеют ST_префикс " ". Это необязательно, и реализации могут отказаться от этого префикса, как это было сделано в различных местах в этом стандарте.

Из этого комитета Проект ИСО / МЭК 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. Кроме того, многие СУБД загрязняют символы этим префиксом.

В истории может быть что-то еще, но я не могу найти более современной информации об этом.

Эван Кэрролл
источник