Add support for Package Public Variables to the Packages implementation [CORE3030]

[firebird-automations]

Submitted by: Alexey Kuznetsov (kuaw26)

Votes: 3

Packages as in CORE2312 feature are lacking variables support.
It would be extremely useful and also would make this feature be more Oracle compatible if variables in packages would be implemented like in Oracle:
"Packaged public variables persist for the duration of a session. So, they can be shared by all subprograms that execute in the environment. Also, they allow you to maintain data across transactions without having to store it in the database."

[firebird-automations]

Commented by: @asfernandes

There are temporary tables you can use to store state per transaction or attachment.

What you propose to fix Oracle problems of state invalidation that cause programs to fail after a package with variables is updated?

[firebird-automations]

Commented by: Sean Leyne (seanleyne)

Edited the description to read better

[firebird-automations]

Modified by: Sean Leyne (seanleyne)

summary: Packages are lacking variable support => Add support for Package Public Variables to the Packages implementation

[firebird-automations]

Commented by: Alexey Kuznetsov (kuaw26)

Temp tables is very "heavy" to be used as storage for simple data and also not "type safe".

Current solution with RDB$SET_CONTEXT() / RDB$GET_CONTEXT() also not "type safe".

With variables server would not compile a trigger for example if I misprint variable name, but if I misprint in sql or RDB$GET_CONTEXT()
trigger would be compiled and error appears only at run time.

As for invalidation - programs should be corrected to reflect changes in package.
Just the same as with regular stored procedure - if you alter procedure params that would case programs to fail.

[firebird-automations]

Commented by: @asfernandes

Temp tables are type safe.

No, you didn't commented out the issue I said. You used Oracle as example, but when you change (i.e., just issue a alter command) a package that has variable in Oracle, it's almost certainly that existing users sessions (in applications) need to restart, as direct or indirect calls to packages causes "existing state of package was lost" exception.