Alvaro Herrera:
> Perhaps the solution to all this is to avoid having the variables be
> implicitly present in the range table of all queries. Instead, if you
> need a variable's value, then you need to add the variable to the FROM
> clause;
+1
This should make it easier to work with composite type schema variables
in some cases. It could also enable schema qualifying of schema
variables, or at least make it easier to do, I think.
In this case variables would share the same namespace as tables and
views, right? So I could not create a variable with the same name as
another table. Which is a good thing, I guess. Not sure how it's
currently implemented in the patch.
I don't like this. Sure, this fixes the problem with collisions, but then we cannot talk about variables. When some is used like a table, then it should be a table. I can imagine memory tables, but it is a different type of object. Table is relation, variable is just value. Variables should not have columns, so using the same patterns for tables and variables has no sense. Using the same catalog for variables and tables. Variables just hold a value, and then you can use it inside a query without necessity to write JOIN. Variables are not tables, and then it is not too confusing so they are not transactional and don't support more rows, more columns.
The problem with collision can be solved very easily - just use a dedicated schema (only for variables) and don't use it in the search path.
In this case, the unwanted collision is not too probable - although it is possible, if you use a schema name for a variable same like table name or alias name.
I can use
CREATE SCHEMA __;
CREATE VARIABLE __.a AS int;
SELECT __.a;
although it is maybe wild, probably nobody will use alias or table name __ and then there should not be any problem
Best,
Wolfgang