> Does your implementation works different than Oracle when changing
> packages with variables?

I'm afraid that Fyracle is sloppy in this area: it does not
invalidate the connection cache upon pacakge changes. So, the
connection continues to work with the old compiled package and the
existing variables. A refresh requires droping & reestablishing the
connection.

If it were better, its only choice would have to be to clear out the
package variables. The variables are stored in a heap
allocated "stack frame" and the opcodes reference them by offset. A
change in the package could reallocate all variables.

I'm not so sure that finding a package suddenly reinitialised is what
a client expects, or should code to expect. Throwing an exception
makes it easier to handle, but still. Perhaps sloppy is not so sloppy.

Note that there is no way for an Oracle client to reinitialise a
package to its initial state (i.e. package variables null or whatever
the default is coded to be), other than dropping/reopening the
connection. This migh be good to have.

For variables to persist across a package update, the package
variables would have to be stored and retrieved by name. Possible,
but a clear break from the lexical scoping / Ada heritage in PL/SQL.
It would be more like the dynamic scoping / Lisp heritage.

Based on gutfeel, I would advise against such persistence. The new
package code would start running on the updated connection with its
variables in a unexpected state, possibly inconsistent with the new
logic.

Paul