Subject | Reserved keywords |
---|---|
Author | Jonathan Neve |
Post date | 2004-11-24T13:14:07Z |
Hi all,
I just have a little question/suggestion. When new features are added to
the engine, that require the use of a new keyword, is it really
necessary to ban that keyword from use as a column/relation? Couldn't
the parser know, in the context, whether it's a field or a keyword? Or
at least in certain cases perhaps? I don't know the internals of how all
this works, but wouldn't it be possible in, for example, the "alter
table" statement, for the engine to understand that "alter table table1
add type integer" means that we're adding a field called "type", whereas
"alter table table1 alter col1 type integer" means that we want to
change the type of a field called "col1"? Would this make SQL
interpretation slower/more difficult? Is that why it's not been done up
till now?
Regards,
Jonathan Neve.
I just have a little question/suggestion. When new features are added to
the engine, that require the use of a new keyword, is it really
necessary to ban that keyword from use as a column/relation? Couldn't
the parser know, in the context, whether it's a field or a keyword? Or
at least in certain cases perhaps? I don't know the internals of how all
this works, but wouldn't it be possible in, for example, the "alter
table" statement, for the engine to understand that "alter table table1
add type integer" means that we're adding a field called "type", whereas
"alter table table1 alter col1 type integer" means that we want to
change the type of a field called "col1"? Would this make SQL
interpretation slower/more difficult? Is that why it's not been done up
till now?
Regards,
Jonathan Neve.