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(at)telsasoft(dot)com
> <mailto:pryzby(at)telsasoft(dot)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(dot)vondra(at)enterprisedb(dot)com
> <mailto:tomas(dot)vondra(at)enterprisedb(dot)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