From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | walther(at)technowledgy(dot)de |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Eisentraut <peter(at)eisentraut(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, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Subject: | Re: Schema variables - new implementation for Postgres 15 |
Date: | 2024-05-22 19:09:54 |
Message-ID: | CAFj8pRAiKkjVZZ+pMz=BGsJn5yY0BZwkXJKJXkie-AdebAOXyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
st 22. 5. 2024 v 20:21 odesílatel <walther(at)technowledgy(dot)de> napsal:
> 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.
>
I don't like this. Sure, this fixes the problem with collisions, but then
we cannot talk about variables. When some is used like a table, then it
should be a table. I can imagine memory tables, but it is a different type
of object. Table is relation, variable is just value. Variables should not
have columns, so using the same patterns for tables and variables has no
sense. Using the same catalog for variables and tables. Variables just hold
a value, and then you can use it inside a query without necessity to write
JOIN. Variables are not tables, and then it is not too confusing so they
are not transactional and don't support more rows, more columns.
The problem with collision can be solved very easily - just use a dedicated
schema (only for variables) and don't use it in the search path.
In this case, the unwanted collision is not too probable - although it is
possible, if you use a schema name for a variable same like table name or
alias name.
I can use
CREATE SCHEMA __;
CREATE VARIABLE __.a AS int;
SELECT __.a;
although it is maybe wild, probably nobody will use alias or table name __
and then there should not be any problem
>
> Best,
>
> Wolfgang
>
From | Date | Subject | |
---|---|---|---|
Next Message | a.rybakina | 2024-05-22 20:31:21 | Sort operation displays more tuples than it contains its subnode |
Previous Message | Pavel Stehule | 2024-05-22 18:44:28 | Re: Schema variables - new implementation for Postgres 15 |