Re: Schema variables - new implementation for Postgres 15

On 11/6/21 16:40, Pavel Stehule wrote:
> 
> 
> so 6. 11. 2021 v 15:57 odesílatel Justin Pryzby <pryzby@telsasoft.com 
> <mailto:pryzby@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.vondra@enterprisedb.com
>     <mailto:tomas.vondra@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