Vlad Khorsun escreveu:

>>>> Security should act on the entire package and not in individual items,
>>>> i.e. we should have GRANT EXECUTE ON PACKAGE <name> ...
>>>>
>>>>
>>> Not sure about it, but lets think more on it...
>>>
>>>
>> It's very useful having DEFINER rights privileges. In Oracle, by default
>> packages uses definer rights.
>>
>
> We may do it for usual PSQL objects too.
>
> Anyway, for relations, for example, we have separate privileges (SELECT, INSERT,
> UPDATE, DELETE). Imagine package which implements procedures to deal with some
> kind of complex objects. It can have procedures for read-only and for read-write work
> with this objects. Why should we use the same privileges for all of this procedures ?
> I.e. we can't separate users which allowed to view objects from users which allowed
> to edit objects.
>

GRANT EXECUTE ON PACKAGE will allow user to run all
procedures/functions, but they will continue run (by default) using
invokers right.

And relation grants to the package will allow all package items to
access them.

I do not see good way to have different privileges for each item without
break the package as one entity concept.

> ...
>
>>> It will not work without changes in remote protocol and API. Remember USHORT's
>>> used for statement text length
>>>
>> For statement length, we could do it using new protocol version like
>> changes done recently, no?
>>
>
> We can change protocol of course, but we need API change also. Its about
> isc_dsql_execute_immediate and isc_dsql_prepare
>

They're easy to change, AFAIK...

>
>>> and BLR length ?
>>>
>> It's not a problem. BLR will be stored separated in rdb$procedures.
>>
>
> isc_ddl also public API ;) Since we have DSQL inside the engine its not a problem
> but if we going to add, say isc_dsql_prepare2,

I don't think it's necessary. They current use USHORT parameter, but
these parameters are passed on the stack as int. Changing it will not
break already compiled/linked applications, and the change will not
cause problems when recompiling.

> why not add isc_ddl2 ? :)
>

I consider isc_ddl as very obsolete thing. BTW, I'm creating new CREATE
FUNCTION for external engines bypassing it like the ALTER CHARACTER SET.

>
>>> Ability to manage individual items in package is good thing and worth implementing,
>>> i believe.
>>>
>>>
>> The problem is that I want to make it as a single entity for upper
>> levels. How changes to procedure body will reflect on package body
>> source, for example?
>>
>
> Are we really need to store whole package body (header) sorce as one unit ? It can be
> easy generated from system tables. Or we can store only VAR part (in Pascal terms) ...
>
> BTW, when do we need whole package header\body ? For documentation purposes ?
> Another usage ? :) It is may be handy to create package by one statement, agreed. But
> later, when we need to alter it - why parse and recompile whole (huge) package ?
>

Packages are good for the user because it can easily break things in
small units more simple. The chance of need to alter various procedures
is greater than with standalone procedures.

Also, current users already "lose" definition of parameters and have
only the body stored in the database. Some people like to have the
"sources" (without others copies) in the database. Recreation will
change order, will change style (lines between items), etc.


Adriano