Re: Rethinking plpgsql's assignment implementation - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Rethinking plpgsql's assignment implementation
Date
Msg-id CAFj8pRBTidG1K_V+=jYMCmvGL9x3EJz7PL6WxWZXr5M0i2OZiA@mail.gmail.com
Whole thread Raw
In response to Re: Rethinking plpgsql's assignment implementation  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


út 19. 1. 2021 v 19:21 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
Hi

Now, I am testing subscribing on the jsonb feature, and I found one issue, that is not supported by parser.

When the target is scalar, then all is ok. But we can have a plpgsql array of jsonb values.

postgres=# do $$
declare j jsonb[];
begin
  j[1] = '{"b":"Ahoj"}';
  raise notice '%', j;
  raise notice '%', (j[1])['b'];
end
$$;
NOTICE:  {"{\"b\": \"Ahoj\"}"}
NOTICE:  "Ahoj"
DO

Parenthesis work well in expressions, but are not supported on the left side of assignment.

postgres=# do $$
declare j jsonb[];
begin
  (j[1])['b'] = '"Ahoj"';
  raise notice '%', j;
  raise notice '%', j[1]['b'];
end
$$;
ERROR:  syntax error at or near "("
LINE 4:   (j[1])['b'] = '"Ahoj"';
          ^

Assignment for nesting composite types is working better - although there is some inconsistency too:

create type t_inner as (x int, y int);
create type t_outer as (a t_inner, b t_inner);

do $$
declare v t_outer;
begin
  v.a.x := 10; -- parenthesis not allowed here, but not required
  raise notice '%', v;
  raise notice '%', (v).a.x; -- parenthesis are required here
end;
$$;

Regards

Pavel


Regards

Pavel


pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: [bug?] EXPLAIN outputs 0 for rows and width in cost estimate for update nodes
Next
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements oddity with track = all