Re: Schema variables - new implementation for Postgres 15
От | Pavel Stehule |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | CAFj8pRD5C2f4qmUi3UuT-9rLZYZAdNUZn55ivymO1UhO6JL_9A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Schema variables - new implementation for Postgres 15
|
Список | pgsql-hackers |
pá 31. 5. 2024 v 15:02 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
pá 31. 5. 2024 v 13:37 odesílatel Wolfgang Walther <walther@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
В списке pgsql-hackers по дате отправления: