| From: | walther(at)technowledgy(dot)de |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, 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, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Subject: | Re: Schema variables - new implementation for Postgres 15 |
| Date: | 2024-05-22 18:21:08 |
| Message-ID: | 42ea2784-192a-476b-8e01-4c62302d00c0@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera:
> Perhaps the solution to all this is to avoid having the variables be
> implicitly present in the range table of all queries. Instead, if you
> need a variable's value, then you need to add the variable to the FROM
> clause;
+1
This should make it easier to work with composite type schema variables
in some cases. It could also enable schema qualifying of schema
variables, or at least make it easier to do, I think.
In this case variables would share the same namespace as tables and
views, right? So I could not create a variable with the same name as
another table. Which is a good thing, I guess. Not sure how it's
currently implemented in the patch.
Best,
Wolfgang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2024-05-22 18:28:48 | Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c) |
| Previous Message | Alvaro Herrera | 2024-05-22 17:27:56 | Re: Schema variables - new implementation for Postgres 15 |