db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER
Date Fri, 24 Feb 2006 02:21:07 GMT
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 <djd@apache.org> 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.
> >
> >
> >
>

Mime
View raw message