[antlr-interest] Upgrade a token/AST from inside the parser.

[Jan H. van der Ven]

Sorry my first response went out to you personally. Luckily the others did
not get my newbie response.
In the meantime i did some reading and coding and headstomping.

My simplified statement parser now sometimes knows when it is dealing with
a table or a column but when i have a common construction like select
table.column from table my cpu rises to 100% even though my ambiguities on
this (there are 2 that I think do not matter) are resolved.

I have attached my .g. The trouble is with the dbObject I think.

The statement that's giving me headaches is: SELECT a.b from C (see how
far I am already ;-)

Please advise.

<quote who="Peggy Fieland">
> I use different token types in the parser, eg
>   SQL_E_COLUMN_NAME
>   SQL_E_TABLE_NAME
> usually in the case of column names, the actual name
> is a child of this node:
> Here is part of the column_name definition for one of
> the databases:
>
>  o0:schema_name DOT!
>             t0:table_name DOT! c0:column_name_ref
>             { ## = #([SQL_E_COLUMN_NAME,
> "COLUMN_NAME"], #c0, #t0, #o0); }
> ...
>
> --- "Jan H. van der Ven" <jhvdven at xs4all.nl> wrote:
>
>> Hi,
>>
>>
>> I am currently working on a SQL parser (we want to
>> support all databases,
>> but I am taking baby steps). I used the MS SQL
>> select statement from
>> Tomasz Jastrzebski that can be downloaded from
>> antlr.org. It checks my
>> statements ok, but that is not the only result I am
>> looking for.
>>
>> What I want is that after the parsing the tokens
>> contain extra information
>> about their syntactic nature. For instance, the
>> parser will find out that
>> a certain 'identifier' is actually a column and I
>> would like that
>> knowledge to become part of the token or the AST.
>>
>> I am new to all of this, so if this is something you
>> guys do all day
>> please let me know.
>>
>> If it is not, could you point me in the right
>> direction.
>>
>>
>> Kind regards,
>>
>>
>> Jan van der Ven
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SQL92Select.g
Type: application/octet-stream
Size: 15767 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20051117/72e05aa9/SQL92Select-0001.obj