| From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-31 11:37:35 |
| Message-ID: | 93728f61-5510-4c7a-9d3f-502edf303d25@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavel Stehule:
> But in this case you could make variables and tables share the same
> namespace, i.e. forbid creating a variable with the same name as an
> already existing table.
>
>
> It helps, but not on 100% - there is a search path
I think we can ignore the search_path for this discussion. That's not a
problem of variables vs tables, but just a search path related problem.
It is exactly the same thing right now, when you create a new table x(x)
in a schema which happens to be earlier in your search path.
The objection to the proposed approach for variables was that it would
introduce *new* ambiguities, which Alvaro's suggestion avoids.
Best,
Wolfgang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yao Wang | 2024-05-31 12:09:53 | Re: 回复: An implementation of multi-key sort |
| Previous Message | Pavel Stehule | 2024-05-31 11:14:19 | Re: Schema variables - new implementation for Postgres 15 |