Re: Schema variables - new implementation for Postgres 15
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Sergey Shinderuk <s.shinderuk@postgrespro.ru>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Julien Rouhaud <rjuju123@gmail.com>, dean.a.rasheed@gmail.com, er@xs4all.nl, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2023-03-03T20:17:57Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow underscores in integer and numeric constants.
- faff8f8e47f1 16.0 cited
-
Remove special outfuncs/readfuncs handling of RangeVar.catalogname.
- 3cece34be842 16.0 cited
-
Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
- 2af33369e794 16.0 cited
-
Create FKs properly when attaching table as partition
- b0284bfb1db5 16.0 cited
-
psql: improve tab-complete's handling of variant SQL names.
- 02b8048ba5dc 15.0 cited
> On Tue, Feb 28, 2023 at 06:12:50AM +0100, Pavel Stehule wrote:
>
> fresh rebase
I'm continuing to review, this time going through shadowing stuff in
transformColumnRef, IdentifyVariable etc. Well, that's a lot of leg work
for rather little outcome :) I guess all attempts to simplify this part
weren't successful?
Couple of questions to it. In IdentifyVariable in the branch handling
two values the commentary says:
/*
* a.b can mean "schema"."variable" or "variable"."field",
* Check both variants, and returns InvalidOid with
* not_unique flag, when both interpretations are
* possible. Second node can be star. In this case, the
* only allowed possibility is "variable"."*".
*/
I read this as "variable"."*" is a valid combination, but the very next
part of this condition says differently:
/*
* Session variables doesn't support unboxing by star
* syntax. But this syntax have to be calculated here,
* because can come from non session variables related
* expressions.
*/
Assert(IsA(field2, A_Star));
Is the first commentary not quite correct?
Another question about how shadowing warning should work between namespaces.
Let's say I've got two namespaces, public and test, both have a session
variable with the same name, but only one has a table with the same name:
-- in public
create table test_agg(a int);
create type for_test_agg as (a int);
create variable test_agg for_test_agg;
-- in test
create type for_test_agg as (a int);
create variable test_agg for_test_agg;
Now if we will try to trigger the shadowing warning from public
namespace, it would work differently:
-- in public
=# let test.test_agg.a = 10;
=# let test_agg.a = 20;
=# set session_variables_ambiguity_warning to on;
-- note the value returned from the table
=# select jsonb_agg(test_agg.a) from test_agg;
WARNING: 42702: session variable "test_agg.a" is shadowed
LINE 1: select jsonb_agg(test_agg.a) from test_agg;
^
DETAIL: Session variables can be shadowed by columns, routine's variables and routine's arguments with the same name.
LOCATION: transformColumnRef, parse_expr.c:940
jsonb_agg
-----------
[1]
-- no warning, note the session variable value
=# select jsonb_agg(test.test_agg.a) from test_agg;
jsonb_agg
-----------
[10]
It happens because in the second scenario the logic inside transformColumnRef
will not set up the node variable (there is no corresponding table in the
"test" schema), and the following conditions covering session variables
shadowing are depending on it. Is it supposed to be like this?