Vlad Khorsun escreveu:

>> Dumb example:
>>
>> SET TERM !;
>>
>> CREATE PACKAGE UTIL
>> AS
>> BEGIN
>> FUNCTION SUBSTRLEN CSTRING(255) NULL, SMALLINT, SMALLINT
>> RETURNS CSTRING(255) FREE_IT
>> ENTRY_POINT 'IB_UDF_substrlen' MODULE_NAME 'ib_udf';
>>
>
> Isn't implementation details (ENTRY_POINT etc) must be in package body instead ?
>

For packages with lot of external items, it will be a problem. With
external info in the header, there is no need to a body.

But we can allow simple declaration in the header with redeclaration
with details in the body.

> ...
>
>
>> 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.

>
>> CREATE PACKAGE creates all procedures with NULL BLR. ALTER PACKAGE and
>> DROP PACKAGE BODY removes all private items and set BLR of all public
>> procedures to NULL. These procedures doesn't run but others could still
>> reference them at compilation time.
>>
>> DROP PACKAGE drops the header and the body.
>>
>> CREATE/ALTER PACKAGE BODY should correctly implement all package
>> procedures declared or will fail completely.
>>
>
> This is Oracle-like behavior, iirc. Imagine package with tens or hundreds objects.
> Oracle recompiles it at every little change. I think we can make it better.
>

Yes, they packages exist as a single entity at they lower levels.

>
>
>> Sources of individual procedures will not be stored. The package header
>> and body sources will be stored in RDB$PACKAGES.
>>
>
> 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?

> and BLR length ?

It's not a problem. BLR will be stored separated in rdb$procedures.

>
>
> 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? And dependencies (see below)?

> Explain, please, more - how do you going to deal with dependencies ?

There will be new object types for RDB$DEPENDENCIES. PACKAGE HEADER and
PACKAGE BODY. Dependent objects of procedure bodies will be in
RDB$DEPENDENCIES using PACKAGE BODY type. Dependent objects (TYPE OF
[COLUMN]) of parameters of public items will be as PACKAGE HEADER.

They will be stored using the package name, and not name of individual
items.


Adriano