> 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.
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).
