Re: Schema variables - new implementation for Postgres 15

út 25. 1. 2022 v 9:48 odesílatel Julien Rouhaud <rjuju123(at)gmail(dot)com> napsal:

> 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?
>

yes, you have true,

Thank you

>
> Couldn't you call something like
>
> lockit = node == NULL;
> varid = IdentifyVariable(cref->fields, &attrname, &not_unique,
> lockit);
>
> The only other caller is transformLetStmt(), which should always lock the
> variable anyway.
>