t-SQL grammar / syntax diagrams 
Author Message
 t-SQL grammar / syntax diagrams
I am trying to look for resources which describe the entire t-SQL grammar
(just the SQL part, don't care for the procedural extensions) either in EBNF
or as Syntax diagrams.

Better still, a parser which generates the Syntax tree. Any help will be
highly appreciated,

TIA,

-- Shashank



Tue, 30 Nov 2004 09:59:34 GMT
 t-SQL grammar / syntax diagrams

Shashank,

The SQL Server Books Online presents BNF for each statement.

-------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which
can be cut and pasted into Query Analyzer is appreciated.


Quote:
> I am trying to look for resources which describe the entire t-SQL grammar
> (just the SQL part, don't care for the procedural extensions) either in
EBNF
> or as Syntax diagrams.

> Better still, a parser which generates the Syntax tree. Any help will be
> highly appreciated,

> TIA,

> -- Shashank



Tue, 30 Nov 2004 11:42:12 GMT
 t-SQL grammar / syntax diagrams


Quote:
> Shashank,

> The SQL Server Books Online presents BNF for each statement.

Sorry, I should have been more specific: I need the t-SQL grammar for
consumption by a parser.

Yes, the BOL has BNF for each statement, but it is for us humans. But
totally unfit (ambiguous, incomplete and inconsistent) for parser generators
like YACC / Bison.

Of course, it can be a good starting point, but I was trying to avoid pain
;-)

Thanks for the suggestion, though.

-- Shashank



Wed, 01 Dec 2004 08:48:59 GMT
 t-SQL grammar / syntax diagrams

Quote:

> Yes, the BOL has BNF for each statement, but it is for us humans. But
> totally unfit (ambiguous, incomplete and inconsistent) for parser
> generators like YACC / Bison.

Given how weird this language is, I doubt that it is even possible to
produce such a thing!

--
Erland Sommarskog, SQL Server MVP

Books Online (updated!) for SQL 2000 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp



Fri, 03 Dec 2004 03:04:07 GMT
 t-SQL grammar / syntax diagrams
Well, the Query Analyzer can analyze it ... so it must possible ;-)

Actually, I have seen the grammar for SQL92 and PL/SQL (Oracle) , so I am
hoping there is one out there for t-SQL too ...

-- Shanko


Quote:

> > Yes, the BOL has BNF for each statement, but it is for us humans. But
> > totally unfit (ambiguous, incomplete and inconsistent) for parser
> > generators like YACC / Bison.

> Given how weird this language is, I doubt that it is even possible to
> produce such a thing!

> --
> Erland Sommarskog, SQL Server MVP

> Books Online (updated!) for SQL 2000 at
> http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp



Sat, 04 Dec 2004 09:15:06 GMT
 t-SQL grammar / syntax diagrams

Quote:

> Well, the Query Analyzer can analyze it ... so it must possible ;-)

I don't think that QA has the entire grammar. It needds to know about
keywords, strings and comment delimiters.

When I said

Quote:
>> Given how weird this language is, I doubt that it is even possible to
>> produce such a thing!

I didn't say it out of the blue. I have been writing code that parses
T-SQL, not completely, but only to find certain items of interest, such
as which tables a query refers to. There are a whole lot of ugly cases
to handle. One reason for this is that T-SQL has unreserved keywords.
That is, a word may be a keyword in some context, but still be a valid
identifier. As far as I can tell that breaks the normal process of first
lexify the code, and the parse the lexical tree.

--
Erland Sommarskog, SQL Server MVP

Books Online (updated!) for SQL 2000 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp



Mon, 06 Dec 2004 05:58:28 GMT
 t-SQL grammar / syntax diagrams
We build program analysis and enhancement tools for
large-scale applications in many languages.
See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.

While we have not yet built a T-SQL parser, we have no doubt that
we can (see our track record at the web site for lots of languages).
We use full-context-free parsing technology.  This technology
can parse langauges with "unreserved" keywords just fine.

Now, the usual problem we run into is that vendors don't
usually publish exact grammars (whether this is conscious
to protect their market, or forgetfulness, laziness,
or siimple inability to write down a clean grammar
for their often-hacked parsing engines is irrelevant).
So to do this, we often have to resort to multiple references
for the language in question, and then we have to validate
by pushing lots of examples at it.
But we are pretty good at this, having done it lots of times.

So, we think T-SQL is fully parseable and processable.
It just takes some empirical effort to get the definition.

--
Ira Baxter, Ph.D. CTO Semantic Designs
www.semdesigns.com  512-250-1018


Quote:

> > Well, the Query Analyzer can analyze it ... so it must possible ;-)

> I don't think that QA has the entire grammar. It needds to know about
> keywords, strings and comment delimiters.

> When I said

> >> Given how weird this language is, I doubt that it is even possible to
> >> produce such a thing!

> I didn't say it out of the blue. I have been writing code that parses
> T-SQL, not completely, but only to find certain items of interest, such
> as which tables a query refers to. There are a whole lot of ugly cases
> to handle. One reason for this is that T-SQL has unreserved keywords.
> That is, a word may be a keyword in some context, but still be a valid
> identifier. As far as I can tell that breaks the normal process of first
> lexify the code, and the parse the lexical tree.

> --
> Erland Sommarskog, SQL Server MVP

> Books Online (updated!) for SQL 2000 at
> http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp



Mon, 06 Dec 2004 23:08:49 GMT
 t-SQL grammar / syntax diagrams

Quote:

> So, we think T-SQL is fully parseable and processable.
> It just takes some empirical effort to get the definition.

I certainly didn't mean to say that T-SQL is not parsable. I am somewhat
in doubt whether you actually can just run it through Yacc or Bison, but
I should gladly admit that I haven?t worked with compilers since I
attended that introductory course on compiler technology at the university
many years ago. T-SQL doesn't seem to have a context-free grammar.

One example on T-SQL could have been easier to parse, is that the semi-
colon as statement terminator is optional. (Was not even available in
6.5 and earlier versions.)

--
Erland Sommarskog, SQL Server MVP

Books Online (updated!) for SQL 2000 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp



Wed, 08 Dec 2004 06:06:53 GMT
 t-SQL grammar / syntax diagrams


Quote:

> > So, we think T-SQL is fully parseable and processable.
> > It just takes some empirical effort to get the definition.

> I certainly didn't mean to say that T-SQL is not parsable. I am somewhat
> in doubt whether you actually can just run it through Yacc or Bison,

.... T-SQL doesn't seem to have a context-free grammar.

You can always build a context-free grammar approximation of a language.
You then need to add other constraints to take into account
context-sensitive
issues.

The problem with YACC/Bison is that a context-free grammar can
be a superset of what they can parse, which is the LALR(1) subset
of context-free languages.     So, if somebody hands you a random
context-free grammar, YACC typically can't do it.

Usually what YACC users do, is take a context free grammar for
a language and hack and hack and hack on the grammar
to produce the LALR(1) subset.

Our tools provide full context-free parsing, so if we can determine
a grammar, we can parse it.   Again, you have to add extra constraints
to handle context-sensitivities.  This typically what name/type checking
is about in most languages.

Quote:
> One example on T-SQL could have been easier to parse, is that the semi-
> colon as statement terminator is optional. (Was not even available in
> 6.5 and earlier versions.)

The optionality of a semicolon doesn't necessary make T-SQL non-LALR(1).
But it doesn't force it to be context-free, either.   What it typically
does is{*filter*}up the 1-token lookahead requirement for YACC.
Depending on your grammar, this can vary.

With context-free parsing, this is simply not an issue.

--
Ira Baxter, Ph.D. CTO Semantic Designs
www.semdesigns.com  512-250-1018



Thu, 09 Dec 2004 00:20:21 GMT
 
 [ 9 post ] 

 Relevant Pages 

1. SQL Diagram Syntax

2. Differences between SyBase TSQL, and SQL Server 2000 TSQL

3. TSQL delimiter syntax for Connection.Execute

4. TSQL syntax checker

5. Syntax Check for TSQL

6. TSQL : ALTER COLUMN to NOT NULL with DEFAULT syntax error

7. TSQL syntax

8. Syntax diagram for Triggers and SP

9. Old Article: Access SQL syntax versus Transact SQL syntax

10. Looking for SQL parser or SQL grammar

11. SQL or PL/SQL grammar

12. BNF grammar for SQL or SQL Plus


 
Powered by phpBB® Forum Software