From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Schema variables - new implementation for Postgres 15 |
Date: | 2022-01-25 08:48:21 |
Message-ID: | 20220125084821.wyacs7zs34olabbp@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2022-01-25 08:52:48 | Re: Schema variables - new implementation for Postgres 15 |
Previous Message | Pavel Stehule | 2022-01-25 08:35:09 | Re: Schema variables - new implementation for Postgres 15 |