Re: Schema variables - new implementation for Postgres 15
От | Pavel Stehule |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | CAFj8pRDWVaM4azo-DMRNemgRtPCW1V2+UdtKz+1sHzuz6j5kqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Wolfgang Walther <walther@technowledgy.de>) |
Ответы |
Re: Schema variables - new implementation for Postgres 15
|
Список | pgsql-hackers |
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 objection to the proposed approach for variables was that it would
introduce *new* ambiguities, which Alvaro's suggestion avoids.
Best,
Wolfgang
В списке pgsql-hackers по дате отправления: