Package with constants. Excessive restrictions for placement of items in the package body

[Pavel Zotov]

Consider script:

============

set bail on;
set autoterm on;
set list on;
set echo on;
shell if exist r:\temp\tmp4test.fdb del r:\temp\tmp4test.fdb;
create database 'localhost:r:\temp\tmp4test.fdb' user sysdba password 'masterkey';

create package pg_test as
begin
    constant k_publ_1 smallint = 1;
    function fn_test returns smallint;
    constant k_publ_2 smallint = 2;
end
;
recreate package body pg_test as
begin
    constant k_priv_1 smallint = -1
    ; --------------------------------------- [ 1 ]
    function fn_test returns smallint as
    begin
        return 1;
    end
    -- ; ------------------------------------ [ 2 ]
    -- constant k_priv_2 smallint = -2; ----- [ 3 ]
end
;

============

IMO, some inconsistency presents currently in the syntax and/or requirement of declaration of package body items.

Comment out "[ 1 ]" or Uncomment lines "[ 2 ]" or "[ 3 ]" -- and you will get "token unknown".

In order words:

1) semicolon is  mandatory after CONSTANT declaration (see "[ 1 ]");

2) semicolon must NOT presend after  `end` that terminates function/procedure (see "[ 2 ]").  But such rule actual only for the BODY of package. For the package HEAD, on the contrary, semicolon is required after each declared constant / unit;

3) all constants in the package BODY must be declared before first unit (proc/func) -- see "[ 3 ]".

Why such rules were introduced ? 

Especially, it is unclear reason of prohibition for ";" to be inserted between items in the package body. 

/* requirement to put all constants at the top looks logical and generally accepted; but then it makes sense to reflect this in the doc ? */

Checked on 6.0.0.1978-12b2158.

[Denis Simonov]

1. That's correct.
2. That's also correct because we never put a semicolon after a compound statement (begin ... end) in PSQL.
3. In your example, a private constant after all the procedures and functions is pointless, since no one can use it. But a constant between routines makes sense.

вторник, 2 июня 2026 г. в 00:13:40 UTC+3, Pavel Zotov:

[Pavel Zotov]

> 3. In your example, [...] no one can use it. But a constant between routines makes sense.

Yes, my origin code that raised error was:

create package pg_test as
begin
    constant k_publ_1 smallint = 1;

    function f_test_1 returns smallint;

    constant k_publ_2 smallint = 2;

    function f_test_2 returns smallint;

end
;
recreate package body pg_test as
begin
    constant k_priv_1 smallint = -1;

    --constant k_priv_2 smallint = -2;
    function f_test_1 returns smallint as
    begin
        return k_priv_1;
    end

    constant k_priv_2 smallint = -2;

    function f_test_2 returns smallint as
    begin
        return k_priv_2;
    end
end
;

 

[Artyom Abakumov]

Pavel Zotov:

3) all constants in the package BODY must be declared before first unit (proc/func) -- see "[ 3 ]".

Why such rules were introduced ? 

 

This is primarily due to a parser limitation. The parser rules for the package body look like this:

symbol_package_name AS BEGIN package_items package_body_items_opt END

The package_items rule contains constant declaration rule and is used in the package header. Adding a constant declaration rule to package_body_items_opt will create a conflict. I tried using %prec to resolve the conflict, but to no avail.

[Adriano dos Santos Fernandes]

So it also means forward declarations cannot be mixed between
implementations section, right?

In this case, it looks fine for me to have constants only in the top
section.


Adriano

[Alex Peshkoff]

On 6/2/26 14:27, Adriano dos Santos Fernandes wrote:

In this case, it looks fine for me to have constants only in the top
section.

+1