RE: sql parser

[Arcadius]

Yes, the sql_yacc.y is used to generate the sql parser. The
parser is used more to "run" the sql rather than to break it into its
tokens. Using the lex files would be closer to your stated goals. The
file lex.h in the same directory as sql_yacc.y contains all the tokens
mysql uses to break apart an SQL statement. sql_lex.cc is the lexer for
mysql, although it is non-trivial code. If your needs are for your
editor to fully understand the SQL statement, look into the lex files.
If your editor only needs to color code stuff, you could possibly get
away with just using the published list of mysql keywords for
highlighting.



-Original Message-
From: Carl Karsten [mailto:[EMAIL PROTECTED] 
Sent: Sunday, November 09, 2003 12:49 AM
To: [EMAIL PROTECTED]
Subject: sql parser


I am looking for code that will take an SQL command and break it into
it's parts.  I have found some attempts, but none that use the code from
an actual SQL engine, and big surprise, they don't work 100%.

I have a few goals:

1) developer tool: cut/paste the SQL command and get a pretty format
display - color, each component on a separate line, sub selects
indented, etc.  How often have you done this by hand and missed a paren?

2) part of an app: user is given a form with a bunch of textbox's.  The
form has a 'basic query' and each textbox has properties defining how to
augment the basic query.  For each input the user gives, augment the
query.  This would be much easier if I had something to break the basic
query up into it's parts.

I am guessing that such a thing does exist, so before I go spelunking
through the source code, perhaps someone can point me somewhere.

It looks like sql_yacc.y is what is used to define the syntax that MySql
uses.  It has been a while sense I took a compiler class, so forgive my
ignorance.  is sql_yacc.y used to generate the parser which is then
compiled, or is it used at runtime?

The goal is to be able to hook into the MySql code without having to
copy it.  That way as MySql evolves, so will my tool.

http://www.personnelware.com/carl/resume.html


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]

RE: Column type

[Arcadius]

I think it would depend on what you are going to do with the
data once it is in the database. If it will only ever be used as a pure
text field, then leaving it as a varchar would not be bad. On the other
hand, if you want to be able to use any of the date fucntions or use it
as a date in a where clause (i.e. WHERE begin >  ), then
I would convert it to one of the date types. This way it could be
indexed. Also, if you only need the date, use a DATE field, as it would
be smaller and thus faster. If you need the time also, use DATETIME.

-Original Message-
From: Ron McKeever [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 17, 2003 10:31 PM
To: [EMAIL PROTECTED]
Subject: Column type


Hi

I have a .txt file that is loaded into my table. This is done using LOAD
DATA INFILE One of the columns data is a unix timestamp from the
.txt file. The column is called begin.

I have created the column as a varchar before
and then converted the date using FROM_UNIXTIME(), so it can be
readable.

My question is:
Should I create this column "begin" as "DATETIME, DATE, or TIMESTAMP" or
since I'm converting the unix time leave it as a varchar???

Thanks,
Ron



-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]