| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, dean(dot)a(dot)rasheed(at)gmail(dot)com, er(at)xs4all(dot)nl, joel(at)compiler(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Schema variables - new implementation for Postgres 15 |
| Date: | 2024-05-22 12:37:49 |
| Message-ID: | 7d117cb6-c4e5-4e87-9bb2-69aa92f8a03a@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikita Malakhov | 2024-05-22 12:46:21 | Re: Shared detoast Datum proposal |
| Previous Message | torikoshia | 2024-05-22 12:25:41 | Re: First draft of PG 17 release notes |