Re: Schema variables - new implementation for Postgres 15
От | Julien Rouhaud |
---|---|
Тема | Re: Schema variables - new implementation for Postgres 15 |
Дата | |
Msg-id | 20220125084821.wyacs7zs34olabbp@jrouhaud обсуждение исходный текст |
Ответ на | Re: Schema variables - new implementation for Postgres 15 (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Schema variables - new implementation for Postgres 15
|
Список | pgsql-hackers |
Hi, On Tue, Jan 25, 2022 at 09:35:09AM +0100, Pavel Stehule wrote: > út 25. 1. 2022 v 6:18 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal: > > > I think the lock should be > > acquired during IdentifyVariable. It should probably be optional as one > > codepath only needs the information to raise a warning when a variable is > > shadowed, so a concurrent drop isn't a problem there. > > > > There is a problem, because before the IdentifyVariable call I don't know > if the variable will be shadowed or not. > > If I lock a variable inside IdentifyVariable, then I need to remember if I > did lock there, or if the variable was locked already, and If the variable > is shadowed and if lock is fresh, then I can unlock the variable. But in transformColumnRef() you already know if you found a matching column or not when calling IdentifyVariable(), so you know if an existing variable will shadow it right? Couldn't you call something like lockit = node == NULL; varid = IdentifyVariable(cref->fields, &attrname, ¬_unique, lockit); The only other caller is transformLetStmt(), which should always lock the variable anyway.
В списке pgsql-hackers по дате отправления: