| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
| Cc: | Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: select (17, 42)::s.t2 into... fails with "invalid input syntax" |
| Date: | 2023-03-09 03:28:04 |
| Message-ID: | CAKFQuwZiR4paFEjiJP4py4HpHBeur=QZqi7Ys1p_XY8-WiCEYw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Mar 8, 2023 at 7:58 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
>
> r := (my_c1, my_c2)::s.t;
>
If you write s.x there it will also work.
Your first and third assignments are identical in syntax/nature. These are
both the first examples here[1]
Yes, the behavior of INTO in the second assignment is somewhat
non-intuitive; but covered here[2]. Probably it could use more examples.
The final form fits into a procedural flow better than the SQL-based one.
Since plpgsql allows for procedural flow this makes sense. The composite
variable reference is simply: main_type_name.field_name Hence the second
example here[1]
[1]
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-ASSIGNMENT
[2]
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2023-03-09 04:53:38 | Re: Behavior of PL/pgSQL function following drop and re-create of a table that it uses |
| Previous Message | Chris Travers | 2023-03-09 03:24:06 | Blog post series on commitfests and patches |