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

It's ok for me

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

...

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

>> 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, why not add isc_ddl2 ? :)

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

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

Ok, understand.

Regards,
Vlad