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
