Спецификация языка T-SQL и правила лексизма

Question

Я думаю о написании шаблонизатора для генерации кода T-SQL, который будет включать разделы с разделителями, как показано ниже;

SELECT 
    ~~idcolumn~~
FROM
    ~~table~~
WHERE
    ~~table~~.flag = 1

Заметили биты, разделяющие двойную тильду? Это идея для escape-последовательности на моем языке шаблонов. Но я хочу быть уверен, что escape-последовательность является действительной - что она никогда не будет встречаться в действительной инструкции T-SQL. Проблема в том, что я не могу найти официального описания Microsoft для языка T-SQL.

Кто-нибудь знает официальную спецификацию языка T-SQL или хотя бы лексические правила? Так что я могу принять обоснованное решение о последовательности побега.

ОБНОВЛЕНИЯ:

Спасибо за предложения, но я не ищу подтверждения escape-последовательности '~~' per se . Мне нужен документ, на который я могу сослаться, на который я могу указать и сказать: «Microsoft говорит, что эта последовательность символов абсолютно невозможна в T-SQL». Например, Microsoft публикует спецификацию языка для C # здесь , которая включает описание того, какие символы могут входить в действующие программы на C #. (см. стр. 67 pdf.) Я ищу похожую ссылку.

Двойная тильда:"~~" на самом деле очень хороший T-SQL. Например; «(SELECT ~~ 1)» возвращает «1».

Answer 1

Неважно, является ли ~~ допустимым TSQL или нет, если вы предоставляете возможность создания ~~ в реальном TSQL, когда вам это нужно.

Поскольку параметры шаблона должны иметь идентификатор ненулевой длины, у вас есть особый случай, когда длина идентификатора смехотворно равна «нулю», например, ~~~~.Такие вещи создают идеальную последовательность, поскольку они бесполезны ни для чего другого.Просто обработайте текст вашего шаблона;всякий раз, когда вы найдете ~~~~, замените его именованной строкой параметра, и всякий раз, когда вы найдете ~~~~, замените его ~~.Теперь, если в окончательном TSQL требуется ~~, просто напишите ~~~~ в своем шаблоне.

Я подозреваю, что даже если вы сделаете это, то число раз, когда вы на самом деле напишите ~~~~ на практике, будет близко к нулю, поэтому причина для этого - теоретическая завершенность и предоставлениетеплое нечеткое чувство, что вы можете написать что-нибудь в шаблоне.

Answer 2

Существует несколько хорошо известных и часто используемых форматов для параметров шаблона, один из которых - $(paramname) (также используется в других сценариях и сценариях T-SQL)

Почему бы не использовать существующий формат?

Answer 3

Вы можете обращаться с цитируемыми литералами и строками как с содержимым, независимо от того, содержат ли они escape-последовательность. Это сделало бы его более надежным.

Запустите текст через лексер, чтобы отделить каждый токен. Если токен является строкой или литералом в кавычках, обрабатывайте его как таковой. Но если это литерал, который начинается и заканчивается на ~~, можно смело предполагать, что это шаблонный заполнитель.

Answer 4

Я не уверен, что вы найдете то, что никогда не произойдет в действительном утверждении. Рассмотрим:

DECLARE @TemplateBreakingString varchar(100) = '~~I hope this works~~'

или

CREATE TABLE [~~TemplateBreakingTable~~] (IDField INT Identity)

Answer 5

Ваша escape-последовательность может встречаться в строковых литералах, но это все.Тем не менее, Microsoft владеет t-sql, и они могут свободно делать все, что хотят, продвигаясь в будущих версиях sql server.Тем не менее, я думаю, что ~~ достаточно безопасно.

Answer 6

Ну, я не уверен насчет полного описания языка, но похоже, что ~~ может встречаться в идентификаторе при условии, что он указан в кавычках (обычно в скобках).

Возможно, вам больше повезет с соглашением о том, что вы не поддерживаете идентификаторы с ~~ в них. Или просто зарезервируйте свои собственные лексические символы и не беспокойтесь о ~~, встречающемся в другом месте.