On 11/6/21 16:40, Pavel Stehule wrote:
so 6. 11. 2021 v 15:57 odesílatel Justin Pryzby <pry...@telsasoft.com
<mailto:pry...@telsasoft.com>> napsal:
On Sat, Nov 06, 2021 at 04:45:19AM +0100, Pavel Stehule wrote:
> st 3. 11. 2021 v 14:05 odesílatel Tomas Vondra
<tomas.von...@enterprisedb.com
<mailto:tomas.von...@enterprisedb.com>> napsal:
> > 1) Not sure why we need to call this "schema variables". Most
objects
> > are placed in a schema, and we don't say "schema tables" for
example.
> > And it's CREATE VARIABLE and not CREATE SCHEMA VARIABLE, so
it's a bit
> > inconsistent.
+1
At least the error messages need to be consistent.
It doesn't make sense to have both of these:
+ elog(ERROR, "cache lookup failed for schema variable
%u", varid);
+ elog(ERROR, "cache lookup failed for variable %u",
varid);
> Yes, there is inconsistency, but I think it is necessary. The name
> "variable" is too generic. Theoretically we can use other
adjectives like
> session variables or global variables and the name will be valid.
But it
> doesn't describe the fundamentals of design. This is similar to the
> package's variables from PL/SQL. These variables are global,
session's
> variables too. But the usual name is "package variables". So schema
> variables are assigned to schemes, and I think a good name can be
"schema
> variables". But it is not necessary to repeat keyword schema in
the CREATE
> COMMAND.
>
> My opinion is not too strong in this case, and I can accept just
> "variables" or "session's variables" or "global variables", but I
am not
> sure if these names describe this feature well, because still
they are too
> generic. There are too many different implementations of session
global
> variables (see PL/SQL or T-SQL or DB2).
I would prefer "session variable".
To me, this feature seems similar to a CTE (which exists for a single
statement), or a temporary table (which exists for a single
transaction). So
"session" conveys a lot more of its meaning than "schema".
It depends on where you are looking. There are two perspectives - data
and metadata. And if I use data perspective, then it is session related.
If I use metadata perspective, then it can be persistent or temporal
like tables.
I think you mean "temporary" not "temporal". This really confused me for
a while, because temporal means "involving time" (e.g. a table with
from/to timestamp range, etc).
I see strong similarity with Global Temporary Tables - but
I think naming "local temporary tables" and "global temporary tables"
can be not intuitive or messy for a lot of people too.
Right, it's a bit like global temporary tables, in the sense that
there's a shared definition but local (session) state.
Anyway, if people will try to find this feature on Google, then
probably use keywords "session variables", so maybe my preference of
more technical terminology is obscure and not practical, and the name
"session variables" can be more practical for other people.
Hmmm, maybe.
If I use the system used for GTT - then the exact name can be "Global
Session Variable". Can we use this name? Or shortly just Session
Variables because we don't support local session variables now.
So a "local variable" would be defined just for a given session, just
like a temporary table? Wouldn't that have the same issues with catalog
bloat as temporary tables?
I'd probably vote for "session variables". We can call it local/global
session variables in the future, if we end up implementing that.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
