#2 seems best to me, i just didn't know if it fit with the current
derby architecture. I think it also has the benefit of least
amount of extra code in the system for a relative infrequent ddl
operation.
As you point out a move toward sharing the alter code will make it
much more likely no special casing needed for future development
directions.
Is there anyone interested in doing some relatively simple parser
work? I would be happy to work as a primary mentor on this project
if anyone is interested. I will file the JIRA.
Satheesh Bandaram wrote:
Hi Mike,
Mike Matrigali wrote:
are 3 options:
1) copy the code to the system procedure
2) use the same method as offline compress, ie. add some internal
syntax so that the whole setup is just done by the parser.
3) somehow call the alter statement node directly from "around"
the parser. I have no idea if this is possible, or how hard.
I would vote for option 2) here... since we already have <ALTER> ....
<COMPRESS> [ <SEQUENTIAL>] production in the parser. Would it be
sufficient to add another token, like [ <OFFLINE> ] and switch the
implementation at execution time? If so, much cleaner than 1) or 3), in
my opinion.
Satheesh
Any opinions on how to get the system procedure inplace compress
to share the alter table execution code?
