Hello Pavel,
> I don't understand to "expensive" word.
Hmmm...
> How much often you create/drop these variables?
Hmmm... As for "session variables" à la MY/MS-SQL, ISTM that a variable is
"created" each time it is asked for, and it disappears completely at the
end of the session... So you can have some kind of minimal SQL scripting
with variables executed server-side, without resorting to a PL. Also
useful in interactive mode, although there the performance is less an
issue.
> The deployment cycle is similar to functions. I don't
> propose any feature, that can enforce bloating of system catalogue.
Hmmm....
> The variable metadata will be persistent across sessions. I can imagine the
> local (temporal) session variable where life cycle of metadata will be
> related to session like our current temporary tables. But it is not in this
> proposal.
So it seems that I misunderstood a key detail in your proposal. Please
accept my apology for my slow witedness. It is better to discuss in front
of a white board...
Now I understand that you want to create a kind of "persistant" session
variable... that is at each new session the variable is instancianted in
the session "automatically", whether the session will use it or not... Or
is it instanciated on demand, i.e. when explicitely accessed?
Could you confirm the interpretation? ISTM that "on demand" would be
better.
As you gathered I was understanding that the "CREATE VARIABLE & GRANTS"
were to be issued in each session for each variable used, inducing catalog
changes each time, hence my quite heavy ranting...
What I understand now is still a somehow strange object, but nevertheless
the CREATE, DROP, GRANT, REVOKE at least are more justified because then
object is somehow really persistent in the database, even if not with a
value.
So I'll have to think about it...
A few more questions:
Bar the grantability, why wouldn't simple session variables work for this
purpose? That is what is the added value of having them "declared"
permanently, compared to created on demand, if the creation is really
light weight?
ISTM that in the Oracle package version, they are linked to PL/SQL, they
are not part of SQL layer itself, so maybe they are only created when some
PL/SQL from the package is invoked, and not created otherwise?
How would this feature interact with a kind of non persistent "simple"
session variables that are found in MY/MS/Oracle SQL? One of my concern is
that such a feature should not preclude other kind of session variables.
And how would it interact with some "fully persistent/shared" variables?
--
Fabien.