SQL is suitable for which kind of parser?

"Casper Bang" <casper@jbr.dk>
24 Mar 2003 21:55:33 -0500

          From comp.compilers

Related articles
SQL is suitable for which kind of parser? casper@jbr.dk (Casper Bang) (2003-03-24)
Re: SQL is suitable for which kind of parser? sreeni@viswanadha.net (Sreenivas Viswanadha) (2003-03-30)
| List of all articles for this month |

From: "Casper Bang" <casper@jbr.dk>
Newsgroups: comp.compilers
Date: 24 Mar 2003 21:55:33 -0500
Organization: Cybercity
Keywords: SQL, parse, question, comment
Posted-Date: 24 Mar 2003 21:55:33 EST

In designing a DBMS with an SQL (89') subset, I now have productions ready
in BNF format. However, I am a bit at a loss whether SQL is a regular
language or "just" a context-free one. Is it correct that a language is said
to be regular, if it only expands (vie productions) to the right?
Furthermore, which parsing method is usually used for SQL? I've met many
fancy words (LL, lR, LALR, SAR etc.) but I think I can solve it by the
logical top-down "recursive decent" method as I've implemented for a much
smaller grammar. Is this method seen as "primitive" (backtracking can occur
where two productions qualify for being applied!)?




--------- Examples (terminals in uppercase) ---------
<direct SQL statement> ::= <sql data statement> <SEMICOLON>


<sql data statement> ::= <create database statement>
  | <create table statement>
  | <select statement>
  | <delete statement>
  | <insert statement>
  | <update statement>
  | <drop table statement>
  | <drop database statement>


<create database statement> ::= CREATE DATABASE <identifier>
<identifier> ::= <simple latin letter> [ { <underscore> | <simple latin
letter> | <digit> }... ]


------------------------------------------------------


Any help will be greatly appreciated! :)
Thanks in advance,
Casper
[Writing a yacc parser for an earlier version SQL wasn't hard. Threre's
one in the archive. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.