Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vXE5i-004gs4-1e for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Dec 2025 07:42:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vXE5g-00BPWL-2z for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Dec 2025 07:42:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vXE5g-00BPWD-1t for pgsql-hackers@lists.postgresql.org; Sun, 21 Dec 2025 07:42:57 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vXE5e-001sWM-1n for pgsql-hackers@lists.postgresql.org; Sun, 21 Dec 2025 07:42:56 +0000 Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-4ee13dc0c52so25396281cf.2 for ; Sat, 20 Dec 2025 23:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766302972; x=1766907772; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bjbYDfmoaMM5rsoX7+RqXB7HX6MYd/Eff82HwzZd1K8=; b=SL/tk/y85SLGabZMrYk6EWnSc/6ZTCDNANudm21V5tRCoN1xW11zDVsvhMKaTdQ9gR j3A9SsKFS/RixiXhYB+2wgzMSCGJMDJUDOlHgGaP6e5gF8HR+BWNxPDOJTVCWtALvqkx GH6PbW7zui+yTokW5aY6GjsBYQHT7F2ZeI3XaOFwkcfHCyHiSca0eESrnisiFdavonc7 zyJSZwQxrwtaPkMfrs8c5ubbxoF9XfwDgqed/ePvGXgUilS1UqUM+l6i0hY6LCL9tcH9 CE2OzxCaDlhLGakmWiqTu4rauvT1d3i7kqLAdQfiHdWeRvXVciEeZHf5g/+TyLfTWzET bx0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766302972; x=1766907772; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bjbYDfmoaMM5rsoX7+RqXB7HX6MYd/Eff82HwzZd1K8=; b=hTKFlj3iWlT+xbmAl9A4IgNNU7GngRVBCSg8U1/VliFIAbiKlg7BNag/g6XGjfXFiY Vgvuno9PYp5MiByLTUOUaYD1Fb1kMlNWlmbZvqf4aisVoNSorkmkNO+PRWhR5FbxtErt XePlU9pT1r6uFoELGc7+MOHHb59woD+tnlTVCGm/Alg7ov5zdc1fNU2B+VptR8iTBG/s bPG4R/H8vTzOJ1ZLlwDmSHy9IqKweIlG6ubS13OhWLrL99eBIeJ3E7+dYnIqeUEOXMpc mccK6INK/w+lPNp4aC6uQ1YPiGfv01Tgp2l2MRtgjMznNdWJY6YJqqGnlIggbwflgZiX DDeg== X-Forwarded-Encrypted: i=1; AJvYcCUDgT3eTot5n28JNldnWYBUo5i3TnaMT4KrhVlFdqAlwcEMKvLZ+BcsMpuZj8+aSE3NwqTG/jKtVHfVresU@lists.postgresql.org X-Gm-Message-State: AOJu0Yy6eqoa1RxzCzmczpJsL08IqG9B7kvHD1v6aucNjcS9DDzZr8ej jfx1bhpsNmAShDirEDHxOQYHyexvbs75ZhCIlHn55PaEvG4xKthc5b7+86Kd5/2yCz8Pyo+XuAi uxwC3h68rFmkyCsE/awXov/r3pGrFFVs= X-Gm-Gg: AY/fxX4sTMPa783e3ztUXsi9uxTbyv6N9zmV2O4mb+KWcLA2pMtXcDLZAW+xT1c/G9Z iMcgWmgxOT+n4FtCDZJyPnVI6EXQb2UOYaOwluZNj9PH/qUTOboY7QTxitsihkZQ6gq8HcYjWeV 4z5F2KlIXOw3bVzAwkwDokrOT6QKSlKEXrKf3DdbChAdbuXn1S15kAXASAWgX+nDm7pgbi7ZjNr SVFi4ZIMaiIjA/NVENMmp0HhTx42w77AZhuZTMy8dPxjbvtLsqB17ofvdGLHKr8HPJNCKr/CobV y8aN/tbnpSGlhPkZ0qKQNw== X-Google-Smtp-Source: AGHT+IH/69k23tzdk48EiEFsZSK06Rh2vziQoZ23f8z3B11RDhdRkhwVayfKPLqbYs1GERwt5/qCjAB85h5ya230PjA= X-Received: by 2002:a05:622a:1b89:b0:4b7:a680:2111 with SMTP id d75a77b69052e-4f4abcd07c2mr109064061cf.8.1766302971927; Sat, 20 Dec 2025 23:42:51 -0800 (PST) MIME-Version: 1.0 References: <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org> <2643645f-2a02-43de-9321-c995ab1b7ef8@postgrespro.ru> <57a94d8a-d7b6-4c5e-9001-be1cd403b172@postgrespro.ru> <54414932-9E82-47AA-902B-2DED18F07F64@gmail.com> <3280c458-a886-4c58-8e2b-4d220b73161d@postgrespro.ru> <09414bf8-9326-431c-9422-b13bddf5f554@postgrespro.ru> <29ff27f5-d359-4479-b11c-ce28e525d806@postgrespro.ru> In-Reply-To: From: Kirill Reshke Date: Sun, 21 Dec 2025 12:42:36 +0500 X-Gm-Features: AQt7F2rlD0zEHCZOo6p9gN6g5z52kxRslS0fD63M3nmwg0eGBy_kL0_Wl72inLw Message-ID: Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands To: Tender Wang Cc: Alexander Korotkov , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="00000000000035209906467175eb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000035209906467175eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 21 Dec 2025, 12:14 Tender Wang, wrote: > > > Alexander Korotkov =E4=BA=8E2025=E5=B9=B412=E6=9C= =8820=E6=97=A5=E5=91=A8=E5=85=AD 19:08=E5=86=99=E9=81=93=EF=BC=9A > >> Hi Tender, >> >> On Sat, Dec 20, 2025 at 5:18=E2=80=AFAM Tender Wang = wrote: >> > I found this feature merged; thanks for this work. >> > I tested it and found that one place in the error errcode may need to >> be changed. >> > In checkPartition(): >> > ... >> > if (get_partition_parent(partRelOid, false) !=3D RelationGetRelid(rel)= ) >> > ereport(ERROR, >> > errcode(ERRCODE_UNDEFINED_TABLE), >> > errmsg("relation \"%s\" is not a partition of relation \"%s\"", >> > ... >> > >> > ERRCODE_UNDEFINED_TABLE usually means "table does not exist." >> > When entering here, the table should exist, otherwise table_open() >> already reports an error. >> > I found another two errcode in checkPartition() use >> ERRCODE_WRONG_OBJECT_TYPE, >> > In the attached patch, I replace ERRCODE_UNDEFINED_TABLE with >> ERRCODE_WRONG_OBJECT_TYPE. >> >> I agree with you that ERRCODE_UNDEFINED_TABLE is certainly wrong error >> code because the table actually exists. ERRCODE_WRONG_OBJECT_TYPE is >> better. For example, we throw it when trying to attach a partition to >> non-partitioned table. So, the parent table type is wrong. However, >> are objects in the situation under consideration really have wrong >> type? The problem is that one table is not partition of another. >> However, it's possibly that they could be attached without changing of >> their types. So, I think about >> ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE. What do you think? >> > > It's ok for me. Please check the v2 patch. > > -- > Thanks, > Tender Wang > On Sun, 21 Dec 2025, 12:14 Tender Wang, wrote: > > > Alexander Korotkov =E4=BA=8E2025=E5=B9=B412=E6=9C= =8820=E6=97=A5=E5=91=A8=E5=85=AD 19:08=E5=86=99=E9=81=93=EF=BC=9A > >> Hi Tender, >> >> On Sat, Dec 20, 2025 at 5:18=E2=80=AFAM Tender Wang = wrote: >> > I found this feature merged; thanks for this work. >> > I tested it and found that one place in the error errcode may need to >> be changed. >> > In checkPartition(): >> > ... >> > if (get_partition_parent(partRelOid, false) !=3D RelationGetRelid(rel)= ) >> > ereport(ERROR, >> > errcode(ERRCODE_UNDEFINED_TABLE), >> > errmsg("relation \"%s\" is not a partition of relation \"%s\"", >> > ... >> > >> > ERRCODE_UNDEFINED_TABLE usually means "table does not exist." >> > When entering here, the table should exist, otherwise table_open() >> already reports an error. >> > I found another two errcode in checkPartition() use >> ERRCODE_WRONG_OBJECT_TYPE, >> > In the attached patch, I replace ERRCODE_UNDEFINED_TABLE with >> ERRCODE_WRONG_OBJECT_TYPE. >> >> I agree with you that ERRCODE_UNDEFINED_TABLE is certainly wrong error >> code because the table actually exists. ERRCODE_WRONG_OBJECT_TYPE is >> better. For example, we throw it when trying to attach a partition to >> non-partitioned table. So, the parent table type is wrong. However, >> are objects in the situation under consideration really have wrong >> type? The problem is that one table is not partition of another. >> However, it's possibly that they could be attached without changing of >> their types. So, I think about >> ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE. What do you think? >> > > It's ok for me. Please check the v2 patch. > > -- > Thanks, > Tender Wang > Hi! Your v2 looks fine The only question for me is, should we add any regression test to exercise this code, or it is not worth the troubles? > --00000000000035209906467175eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, 21 Dec 2025, 12:14 = Tender Wang, <tndrwang@gmail.com> wrote:


Alexander Korotkov <aekorotkov@gmail.com> =E4= =BA=8E2025=E5=B9=B412=E6=9C=8820=E6=97=A5=E5=91=A8=E5=85=AD 19:08=E5=86=99= =E9=81=93=EF=BC=9A
Hi Tender,

On Sat, Dec 20, 2025 at 5:18=E2=80=AFAM Tender Wang <tndrwang@gmail.com<= /a>> wrote:
> I found this feature merged; thanks for this work.
> I tested it and found that one place in the error errcode may need to = be changed.
> In checkPartition():
> ...
> if (get_partition_parent(partRelOid, false) !=3D RelationGetRelid(rel)= )
>=C2=A0 =C2=A0 =C2=A0ereport(ERROR,
>=C2=A0 =C2=A0 =C2=A0errcode(ERRCODE_UNDEFINED_TABLE),
>=C2=A0 =C2=A0 =C2=A0errmsg("relation \"%s\" is not a par= tition of relation \"%s\"",
> ...
>
> ERRCODE_UNDEFINED_TABLE usually means "table does not exist."= ;
> When entering here, the table should exist, otherwise table_open() alr= eady reports an error.
> I found another two errcode in checkPartition() use ERRCODE_WRONG_OBJE= CT_TYPE,
> In the attached patch, I replace ERRCODE_UNDEFINED_TABLE with ERRCODE_= WRONG_OBJECT_TYPE.

I agree with you that ERRCODE_UNDEFINED_TABLE is certainly wrong error
code because the table actually exists.=C2=A0 ERRCODE_WRONG_OBJECT_TYPE is<= br> better.=C2=A0 For example, we throw it when trying to attach a partition to=
non-partitioned table.=C2=A0 So, the parent table type is wrong.=C2=A0 Howe= ver,
are objects in the situation under consideration really have wrong
type?=C2=A0 The problem is that one table is not partition of another.
However, it's possibly that they could be attached without changing of<= br> their types.=C2=A0 So, I think about
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE.=C2=A0 What do you think?

It's ok for me. Please check the v2 patch.= =C2=A0

-- =
Thanks,
Tender Wang


On Sun, 21 Dec 2025, 12:14 Ten= der Wang, <tndrwang@gmail.com&= gt; wrote:


Alexander Korotkov <aekorotkov@gmail.com> =E4= =BA=8E2025=E5=B9=B412=E6=9C=8820=E6=97=A5=E5=91=A8=E5=85=AD 19:08=E5=86=99= =E9=81=93=EF=BC=9A
Hi Tender,

On Sat, Dec 20, 2025 at 5:18=E2=80=AFAM Tender Wang <tndrwang@gmail.com<= /a>> wrote:
> I found this feature merged; thanks for this work.
> I tested it and found that one place in the error errcode may need to = be changed.
> In checkPartition():
> ...
> if (get_partition_parent(partRelOid, false) !=3D RelationGetRelid(rel)= )
>=C2=A0 =C2=A0 =C2=A0ereport(ERROR,
>=C2=A0 =C2=A0 =C2=A0errcode(ERRCODE_UNDEFINED_TABLE),
>=C2=A0 =C2=A0 =C2=A0errmsg("relation \"%s\" is not a par= tition of relation \"%s\"",
> ...
>
> ERRCODE_UNDEFINED_TABLE usually means "table does not exist."= ;
> When entering here, the table should exist, otherwise table_open() alr= eady reports an error.
> I found another two errcode in checkPartition() use ERRCODE_WRONG_OBJE= CT_TYPE,
> In the attached patch, I replace ERRCODE_UNDEFINED_TABLE with ERRCODE_= WRONG_OBJECT_TYPE.

I agree with you that ERRCODE_UNDEFINED_TABLE is certainly wrong error
code because the table actually exists.=C2=A0 ERRCODE_WRONG_OBJECT_TYPE is<= br> better.=C2=A0 For example, we throw it when trying to attach a partition to=
non-partitioned table.=C2=A0 So, the parent table type is wrong.=C2=A0 Howe= ver,
are objects in the situation under consideration really have wrong
type?=C2=A0 The problem is that one table is not partition of another.
However, it's possibly that they could be attached without changing of<= br> their types.=C2=A0 So, I think about
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE.=C2=A0 What do you think?

It's ok for me. Please check the v2 patch.= =C2=A0

-- =
Thanks,
Tender Wang


--00000000000035209906467175eb--