Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDTRk-0000tX-9P for pgsql-sql@arkaria.postgresql.org; Sat, 20 Feb 2021 14:41:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lDTRi-0002wZ-TN for pgsql-sql@arkaria.postgresql.org; Sat, 20 Feb 2021 14:41:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDTRi-0002wS-JS for pgsql-sql@lists.postgresql.org; Sat, 20 Feb 2021 14:41:22 +0000 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lDTRb-0004ZA-Md for pgsql-sql@lists.postgresql.org; Sat, 20 Feb 2021 14:41:22 +0000 Received: by mail-ed1-x52d.google.com with SMTP id l12so15903380edt.3 for ; Sat, 20 Feb 2021 06:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance; bh=BLkMXbdd2EGwyxYgrG7gObc6z5T91ZlCq4chjKgHHbU=; b=Ay9xxTJ/p6VU+ZT9+1CjxLZSlJNGMvl9IPfiKQdz/tRFX/GzNauXKmhRhmq9CPY7WH 8hcDO77b+A0vCLNjcThWX5iTeG19iWNcspvAMXuYvDbzA1FPIrYiechxKrZWiLlEWk3R 59LHvOgDyS14T1tcYBsspfFM8LUH/POEk5/Sc2Cyhf3dPiIQOraxHNGSFjF2IOMxBtHE JqImk26zpJFzMSsHBuQDp8x22ad7Ea8vBuu7c941jJCanGEDXFikT2H7vJIi13NUMawp aB34R3KMmwU8esV5UxvGSxsvJdKWWtDR+dnujIvzv2ao4w3n7Bad5CEOnn2uAWJYYGkB TFHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance; bh=BLkMXbdd2EGwyxYgrG7gObc6z5T91ZlCq4chjKgHHbU=; b=YzaKn5V9NatySX5g9/d0qKFpXrdPdJq0y3x8KSO6OoQmNFRbmjvKx0hKC1Pl0mmG/a xLSOJhPbt2+sSfc9zdzbT9ZleiTwVVX5gO/dm8g7+8JqL/XC/dSJYYyei9pkXDSQiw1j zJ6lbA5rAWV7r2g+w1kWWKRJfWJuE4piR5yw5snxe1XWSl7qQ4i0IFgzpbydhT+gg2mw VYUjwl0SO1uBvhQIXv2fDfS1EJHYGXy3aBxasA9lJ4IN4RysZBDVjMyAPqyeX6cyhURa VGtcWYNt1u1mwefk+6Gg5XQMWV170GScNmy7GeDT5Kv0wxjynJ/MMHoUQIJ0KjxbQdwC AhhA== X-Gm-Message-State: AOAM530c3qfP1Rw3S454ZrTG1ENnlkliqCTCtYP5PfJVuoHZ5ZjnrNYC oKzg3v5QNjOlPMLt8tXMUNy1u0VQhvB5 X-Google-Smtp-Source: ABdhPJyW93SUcVZ0TjVDwA5mG9OHt4iPuIneoxha7wAEKdZrkCPeSAs88rqi7Aahm6dcFKgaxs1z2Q== X-Received: by 2002:aa7:c555:: with SMTP id s21mr14096879edr.43.1613832073866; Sat, 20 Feb 2021 06:41:13 -0800 (PST) Received: from ?IPv6:2001:171b:226d:d1d0:29d6:f7b8:46c5:9bf1? ([2001:171b:226d:d1d0:29d6:f7b8:46c5:9bf1]) by smtp.gmail.com with ESMTPSA id pk5sm2568205ejb.119.2021.02.20.06.41.12 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Feb 2021 06:41:13 -0800 (PST) Message-ID: <60311f89.1c69fb81.3220e.2fd4@mx.google.com> MIME-Version: 1.0 To: "pgsql-sql@lists.postgresql.org" From: Arturo Guadagnin Subject: embedded composite types Date: Sat, 20 Feb 2021 15:41:09 +0100 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_BA9CF298-8F8F-4D3B-BF4D-00078F36D120_" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_BA9CF298-8F8F-4D3B-BF4D-00078F36D120_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I have defined a composite type containing attributes of an other composite= type, e.g. create type MyPoint as ( x int, y int ); create Type Point2 as ( pt1 MyPoint, pt2 MyPoint ); accessing the first level using the dot operator works flawlessly, e.g. do $$ DECLARE p MyPoint; BEGIN p.x :=3D 1; p.y :=3D 2; RAISE NOTICE 'p=3D%', p; END; $$ p=3D(1,2) But trying to navigate further gives an error: do $$ DECLARE p Point2; x int; BEGIN p.pt1 :=3D (1,2); p.pt2 :=3D (3,4); x :=3D p.pt1.x; END; $$ [42P01] ERROR: missing FROM-clause entry for table "pt1" Where: PL/pgSQL function inline_code_block line 8 at assignment doing it in 2 separate steps works (but is not nice) do $$ DECLARE p Point2; pt1 MyPoint; x int; BEGIN p.pt1 :=3D (1,2); pt1 :=3D p.pt1; x :=3D pt1.x; END; $$ I=E2=80=99m just wondering whether this is the expected behaviour or if the= re is any syntactical magic I=E2=80=99m not aware of .... --_BA9CF298-8F8F-4D3B-BF4D-00078F36D120_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" 
I have defined a composite type containing attributes =
of an other composite type, e.g.
 =

=
create type MyPoint as (
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x int,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 y int
=C2=A0=C2=A0=
=C2=A0 );

create Type Point2=
 as (
=C2=A0=C2=A0=C2=A0 pt1 MyPoi=
nt,
=C2=A0=C2=A0=C2=A0 pt2 MyPoint
);

 

accessing the first level using the dot operator = works flawlessly, e.g.

 

do $$
DECLARE
= =C2=A0=C2=A0=C2=A0 p=C2=A0 MyPoint;=
BEGIN
=C2=A0=C2=A0=C2=A0 p.x :=3D 1;
=C2=A0=C2=A0=C2=A0 p.y :=3D 2;
=C2= =A0=C2=A0=C2=A0 RAISE NOTICE 'p=3D%', p= ;
END;
$$

&= nbsp;

p=3D(1,2)

 

<= p class=3DMsoNormal>But trying to navigate further gives an error:

 

 = 

do <=
/span>$$
D=
ECLARE
=C2=A0=C2=A0=C2=A0 p=C2=A0=
 Point2;
=C2=A0=C2=A0=C2=A0 x int<=
/span>;
BEGIN
=C2=A0=C2=A0=C2=A0 p.p=
t1 :=3D (1,2=
);
=C2=A0=C2=A0=C2=A0 p.pt2 :=3D (3,4=
);
=C2=A0=C2=A0=C2=A0 x :=3D p.pt1.x;
END;
$$

[42P01] ERROR=
: missing =
FROM-clause entry for table "p=
t1"
Where: PL/pgSQL function =
inline_code_block line 8 at assignment
 
doing it in 2 separate steps works (bu=
t is not nice)
 
do =
$$
DECLARE
=C2=A0=C2=A0=C2=A0 p=C2=A0 Point2;
=C2=A0=C2=A0=C2=A0 pt=
1 MyPoint;
=C2=A0=C2=A0=C2=A0 x in=
t;
BEGIN
=C2=A0=C2=A0=C2=A0 p=
.pt1 :=3D (1,2);
=C2=A0=C2=A0=C2=A0 pt1 :=3D p.pt1;
=C2=A0=C2=A0=C2=A0 x :=3D pt1=
.x;
END;
$$
 

I=E2=80=99m just wondering whether this is the expected be= haviour or if there is any syntactical magic I=E2=80=99m not aware of ....<= /p>

 

&nbs= p;

 

= --_BA9CF298-8F8F-4D3B-BF4D-00078F36D120_--