Pavel Stehule: > But in this case you could make variables and tables share the same > namespace, i.e. forbid creating a variable with the same name as an > already existing table. > > > It helps, but not on 100% - there is a search path
I think we can ignore the search_path for this discussion. That's not a problem of variables vs tables, but just a search path related problem. It is exactly the same thing right now, when you create a new table x(x) in a schema which happens to be earlier in your search path.
I don't think it is a valid argument - search_path is there, and we cannot ignore it, because it allows just one case.
And the need to use a variable in FROM clause introduces implicit unpacking or inconsistency with current work with composite's types, so I am more sure this way is not good.
The session variables can be used in queries, but should be used in PL/pgSQL expressions, and then the mandatory usage in FROM clause will do lot of problems and unreadable code like
DO $$
BEGIN
RAISE NOTICE '% %', (SELECT x FROM x), (SELECT a,b FROM y);
END
$$
This requirement does variables unusable in PL
The objection to the proposed approach for variables was that it would introduce *new* ambiguities, which Alvaro's suggestion avoids.
