Re: proposal: schema variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: schema variables |
| Дата | |
| Msg-id | CAFj8pRCeh3u9rSqq0me52iik9+pNUvYeb8OgbuFxJArrb4VDjA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: schema variables (Wolfgang Walther <walther@technowledgy.de>) |
| Ответы |
Re: proposal: schema variables
|
| Список | pgsql-hackers |
so 16. 11. 2024 v 15:56 odesílatel Wolfgang Walther <walther@technowledgy.de> napsal:
Dmitry Dolgov:
> This sounds to me like an argument against allowing name clashing between
> variables and tables. It makes even more sense, since session variables are in
> many ways similar to tables.
+1
It doesn't help too much, because the unique tuple (schema, name), and there is a search path.
Secondly, the pg_class is not good enough for description of scalar variables, and enhancing pg_class for scalar variables can be messy.
My mental model of a session variable is similar to a single-row,
optionally global temporary, table.
Is there any substantial difference that I am not aware of?
What I know, the variables are used as query parameters, not as relations - Oracle, DB2, MSSQL, MySQL, ...
semantically, yes - it is a global temporary object, but it can be scalar or composite value - it is not row.
(global (temp)) table can hold 0, 1 or more rows (and rows are always composite of 0..n fields). The variable holds a value of some type. Proposed session variables are like plpgsql variables (only with different scope). In Postgres there is a difference between a scalar variable and composite variable with one field.
Regards
Pavel
Best,
Wolfgang
В списке pgsql-hackers по дате отправления: