T-SQL言語仕様とレキシング規則

Question

T-SQLコードを生成するためのテンプレートツールを作成しようと考えています。これには以下のような区切りのセクションが含まれています。

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

ビットを区切るダブルティルダに注意してください。これは私のテンプレート言語のエスケープシーケンスのアイデアです。しかし、私はエスケープシーケンスが有効であることを確かめたい - それは有効なT-SQLステートメントでは起こりません。問題は、私はT - SQL言語の公式のマイクロソフトの説明を見つけることができませんです。

T-SQL言語の公式仕様、または少なくともレキシング規則を知っている人はいますか？だから私はエスケープシーケンスについて情報に基づいた決定をすることができます。

UPDATES：これまでに提案を

おかげで、私はそれ自体が「~~」エスケープシーケンスの確認を探していませんよ。私が必要とするのは、私が指し示すことができる参考文献であり、「マイクロソフトはこの文字シーケンスはT-SQLでは全く不可能だと言っている」と述べている。たとえば、マイクロソフトはC＃hereの言語仕様を公開しています。これには、有効なC＃プログラムに含まれる文字の説明が含まれています。 （pdfの67ページを参照してください）私は同様のリファレンスを探しています。

ダブルチルダ：「~~」は実際には完全に優れたT-SQLです。例えば; "（SELECT ~~ 1）"は "1"を返します。

Answer 1

まあ、私は言語の完全な説明についてはわかりませんが、identifierの中では（大括弧で囲まれていれば）~~が出現する可能性があります。

あなたは、識別子が~~であることをサポートしていないという慣習には、より多くの運があるかもしれません。または、自分の字句記号を予約して、~~が他の場所で発生する心配はありません。

Answer 2

テンプレートパラメータのためのいくつかのよく知られており、頻繁に使用される形式がありますが、1例は$(paramname)は、なぜ既存のフォーマットを使用していない

（また、他のスクリプトと同様にT-SQLスクリプトで使用される）されていますか？

Answer 3

エスケープシーケンスは文字列リテラルでも発生する可能性がありますが、それだけです。つまり、マイクロソフトはt-SQLを所有しており、将来のバージョンのSQL Serverのために必要な作業を自由に行うことができます。それでも、~~は安全だと思います。

Answer 4

はありません。は有効なステートメントで発生します。考えてみましょう：

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

または

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

Answer 5

あなたは彼らがあなたのエスケープシーケンスが含まれているかどうかに関係なく、コンテンツとして引用リテラルと文字列を扱うことができます。それはより堅牢になります。

各トークンを分離するために、語句トラッカーを実行します。トークンが文字列または引用符で囲まれたリテラルの場合は、それをそのまま扱います。しかし、それが始まり、~~で終わるリテラルであれば、それがテンプレートプレースホルダであると見なすことができます。

Answer 6

実際のTSQLで必要なときに~~を生成するためのエスケープを指定すると、~~が有効なTSQLであるかどうかは関係ありません。

テンプレートパラメータは非ゼロ長識別子を有する必要があるので、あなたが~~~~、例えば、識別子の長さは、途方もなく「ゼロ」である特有のケースを持っています。この種のものは理想的なエスケープシーケンスを作ります。なぜなら、他のものにとっては役に立たないからです。テンプレートテキストを処理するだけです。あなたが~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~最終的なTSQLで~~が必要な場合は、テンプレートに~~~~を書きます。

実際に~~~~を書き込む回数はゼロに近いと思われます。その理由は理論的には完全であり、暖かいファジーあなたはテンプレートに何かを書くことができると感じます。