Hi st 22. 5. 2024 v 16:14 odesÃlatel Dmitry Dolgov <9erthali...@gmail.com> napsal:
> > On Wed, May 22, 2024 at 02:37:49PM +0200, Peter Eisentraut wrote: > > On 18.05.24 13:29, Alvaro Herrera wrote: > > > I want to note that when we discussed this patch series at the dev > > > meeting in FOSDEM, a sort-of conclusion was reached that we didn't want > > > schema variables at all because of the fact that creating a variable > > > would potentially change the meaning of queries by shadowing table > > > columns. But this turns out to be incorrect: it's_variables_ that are > > > shadowed by table columns, not the other way around. > > > > But that's still bad, because seemingly unrelated schema changes can make > > variables appear and disappear. For example, if you have > > > > SELECT a, b FROM table1 > > > > and then you drop column b, maybe the above query continues to work > because > > there is also a variable b. Or maybe it now does different things > because b > > is of a different type. This all has the potential to be very confusing. > > Yeah, that's a bummer. Interestingly enough, the db2 implementation of > global session variables mechanism is mentioned as similar to what we > have in the patch. But weirdly, the db2 documentation just states > possibility of a resolution conflict for unqualified names, nothing > else. > I found document https://www.ibm.com/docs/it/i/7.3?topic=variables-global If I understand well, then the same rules are applied for qualified or not qualified identifiers (when there is a conflict), and the variables have low priority. The db2 has the possibility to compile objects, and it can block the usage variables created after compilation - (if I understand well the described behaviour). Regards Pavel
