Package constants

[Noremos]

This PR adds a new database object - Package Constant (#1036). See README.packages.txt for more information.
Usage examples:

set autoterm;
CREATE PACKAGE MY_PACKAGE
AS
BEGIN
    CONSTANT PUBLIC_CONST INTEGER = 10;
    FUNCTION MY_SECRET_PRINT() RETURNS INT;
END;

CREATE PACKAGE BODY MY_PACKAGE
AS
BEGIN
    CONSTANT SECRET_1 INTEGER = 15;
    CONSTANT SECRET_2 INTEGER = 30;

    FUNCTION MY_SECRET_PRINT() RETURNS INT
    AS
    BEGIN
        RETURN SECRET_1 * SECRET_2;
    END
END;
commit;

select MY_PACKAGE.PUBLIC_CONST from rdb$database ;
select MY_PACKAGE.MY_SECRET_PRINT() from rdb$database;

The implementation has three key points:

1. The package constants code is flexible enough to implement package variables, global constants, and additional package elements.
2. All nodes now have an 'is constant' flag, similar to the 'is deterministic' flag. This is necessary to determine whether an expression can initialize a constant.
3. In the CreateAlterPackageNode node, a lot of code had to be copied and pasted, and adding constants led to complete chaos. Therefore, I decided to slightly refactor this node. All functionality remains the same; only code duplication was removed.

[sim1984]

Are comments supported for constants? I didn't see this in the documentation.
Let me clarify what I mean:

COMMENT ON CONSTANT [<schema>.]<package>.<const_name> IS 'Text'

Comments are simply supported for packaged procedures and functions. It would make sense to do the same for constants (and any package objects, for that matter).

COMMENT ON PROCEDURE [<schema>.]<package>.<proc_name> IS 'Text';
COMMENT ON FUNCTION [<schema>.]<package>.<func_name> IS 'Text';

[Noremos]

Are comments supported for constants?

No, I didn't plan to implement comments, but I think it's possible. I will take a look

[Noremos]

Maybe it should be refactored, so that Routine and Constant have the same base class?

I'll try. I hope I can make as few changes as possible.

[Noremos]

I'm currently almost done refactoring the constants to use the package cache object, but there are two main issues:

1. Package is split into a header and a body. So, whenever the body changes, I have to call MetadataCache::newVersionCached::Package. This isn't a problem, but it might be better to implement two metadata object types: PackageHeader and PackageBody. From a metadata perspective, this seems more correct, but I'm not sure.
2. The new code is completely different from my original implementation, which essentially consists of ready-to-use global constants. So what should I do with the old code?
   a) Leave this for global constants (if there are any at all)
   b) Implement global constants in this PR
   c) Create a separate PR with global constants.

As far as I can see, the only open issue regarding global constants is name collision resolution.

[sim1984]

As far as I can see, the only open issue regarding global constants is name collision resolution.

IHMO, global constants don't need to be implemented. As far as I know, no relational DBMS has implemented constants in this way. It seems to me that any non-standard extensions that can be used in DSQL should, if possible, be kept within packages.

[asfernandes]

No code change in scl.epp?
Did you missed permissions check?

[Noremos]

No code change in scl.epp?
Did you missed permissions check?

Hmm, I thought that since constants aren't independent objects, it would be enough if the user had permission to create a package. Should I add separate permissions for creating constants?

[asfernandes]

Hmm, I thought that since constants aren't independent objects, it would be enough if the user had permission to create a package. Should I add separate permissions for creating constants?

I'm referring to the outside user of a constant, which should have permission to use the package.

[sim1984]

Known issues:

1. Id for system packages is missing

Does this mean constants in system packages are impossible?

I'd really like to see constants in system packages too. Some examples:

1. RDB$BLOB_UTIL package. RDB$BLOB_UTIL.SEEK function. It has a MODE parameter for setting the search mode. The magic values ​​aren't at all obvious. I'd like to have constants:

• FROM_BEGIN = 0
• FROM_CURRENT = 1
• FROM_END = 2

2. RDB$PROFILER package. RDB$PROFILER.START_SESSION function. It has a PLUGIN_OPTIONS parameter. One of the options is the string literal 'DETAILED_REQUESTS'. This isn't obvious either; you can easily misspell the string literal and there won't be any error. A constant for this would be nice too.

• DETAILED_REQUESTS_OPT = 'DETAILED_REQUESTS'

[Noremos]

Known issues

These issues are temporary and will be fixed. I don't think adding constants to system packages will be a problem

[Noremos]

I'm referring to the outside user of a constant, which should have permission to use the package

Got it. I will add a the permission check

[sim1984]

Are the ID ranges for user packages and system packages somehow separated?

I'm saying this because the number of system packages will expand over time. Couldn't the ID assigned to a user package be overwritten when restored by a new ID for a system package (in a new Firebird version)?