Based on pros and cons listed by Dan, it seems like it would be better to continue with the existing paradigm of RoutineAliasInfo for the new column. So, I will go ahead and make changes in my codeline to put invoker security info in RoutineAliasInfo.
thanks,
Mamta
On 2/23/06, Daniel John Debrunner < [EMAIL PROTECTED]> wrote:Mamta Satoor wrote:
> I chose to have a new column in SYSALISES rather than expanding
> RoutineAliasInfo becasue, like Satheesh brought it up in his following
> comment below, metadata extraction won't be straightforward if it was
> part of RoutineAliasInfo.
> "It would become harder to extract this info from RoutineAliasInfo as it
> is a Java object for any metadata processing... like in dblook or for
> other GUI tools. We would have to document how RoutineAliasInfo gets
> generated as a character type and maintain that format in the future."
But that's the case today. The toString() output is used by dblook. Is
there any specific requirement for the invoker security to be separate
from the rest of the information stored in RoutineAliasInfo, when
accessed through SQL?
Seems like this to me:
new column
upgrade code
dblook additional code
RoutineAliasInfo
no upgrade change
no dblook change
change self contained in RoutineAliasInfo
I was planning at some point to add some other routine attributes to
RoutineAliasInfo, just trying to understand why a change in existing
paradigm is happening.
Thanks,
Dan.
