pá 31. 5. 2024 v 15:02 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther < > walt...@technowledgy.de> napsal: > >> 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. >> >> Best, >> >> Wolfgang >> >
