No, there is no specific requirement for invoker security to be different.
The reason I brought up the issue of what would be a good place to store this is, I remember seeing on dev list that metadata extraction is not straight forward with objects in system tables. And then I also noticed the comment in the code
CreateAliasNode.init line 195
// GrantRevoke TODO: Figure out how to save external security info. Putting this in
// RoutineAliasInfo may not be the best long term solution
// RoutineAliasInfo may not be the best long term solution
And so I wanted to get a feedback to see what would be an ideal place to keep invoker security information.
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.
