Re: Schema variables - new implementation for Postgres 15
От | Tomas Vondra |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | fd0c0bea-fbf5-5465-4b03-999c4a7448ac@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Следующее
От: Tomas VondraДата:
Сообщение: Re: Schema variables - new implementation for Postgres 15