Message-ID: <26fe1a14-89aa-415d-a1b1-176526e54d3b@postgrespro.ru>
Date: Wed, 11 Jun 2025 16:10:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Junwang Zhao <zhjwpku@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: 
 <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
 <4e2764f7-f6be-478f-8d7f-f921dbd10f5f@postgrespro.ru>
 <CAPpHfdv2V2tsvVn5LYyrJkzmPA==vbdCEKiT8j9yaaiDTfaQtA@mail.gmail.com>
 <ff30dc7e-ebca-42a2-9d49-a66c9a3c7ee5@postgrespro.ru>
 <CALDaNm3V5DQSbZGxhYH+3MMMm-YdgOg+RdJ-ni6D0TZx_=Xd7w@mail.gmail.com>
 <7fdaf3e8-4c05-4739-bee6-98acc068d1c7@postgrespro.ru>
 <CAPpHfduH83+CW1dBppFVjxauPFGC+-ux+Y7wB0koZJCs029SXA@mail.gmail.com>
 <4433b492-9e97-4334-96d9-ddaaa5083099@postgrespro.ru>
 <CACJufxEi_JVg+=_BSS0o+TYUE_Hq+jmga_yxxuKLSGbQiAnZDg@mail.gmail.com>
 <67ecf5fb-e63d-4284-be75-d0479eef81aa@postgrespro.ru>
 <CACJufxFGPLTDW55bgaBTH1uCf0=YUZUVKWFrTBvOZNYKc49MxA@mail.gmail.com>
 <CACJufxHHnJm6Jb2YQpuRU1RX__tO=JJNJ5=EUMuzif_KNxGd9A@mail.gmail.com>
 <CACJufxFkscyhak2cSr8t+EPfwv11yccfEZBBnPbX4tRc_mWkXQ@mail.gmail.com>
 <884bcf9e-d6e3-4b0c-8dcb-7f2110070ac9@postgrespro.ru>
 <CAEG8a3Lpw-h+T+Pfqcchyc9mp0r5UcWT5+uZYsew=1ZSkg-H+w@mail.gmail.com>
Content-Language: en-US
From: Dmitry Koval <d.koval@postgrespro.ru>
In-Reply-To: 
 <CAEG8a3Lpw-h+T+Pfqcchyc9mp0r5UcWT5+uZYsew=1ZSkg-H+w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/26fe1a14-89aa-415d-a1b1-176526e54d3b%40postgrespro.ru>
Precedence: bulk

Hi, Junwang Zhao!

Thank you for note.

1.
 >Would it be better to use RELATION_IS_OTHER_TEMP in this case?
 >I noticed that while other parts of tablecmds.c don=E2=80=99t use the m=
acro,
 >all other files consistently use RELATION_IS_OTHER_TEMP.

Agreed, RELATION_IS_OTHER_TEMP is better. Changed.
The fix will be in the next patch.


2.
 >+/*
 >+* We intended to create the partition with the same persistence as the
 >+* parent table, but we still need to recheck because that might be
 >+* affected by the search_path.  If the parent is permanent, so must be
 >+* all of its partitions.
 >+*/

 >I have trouble understanding how this is possible, can you kindly
 >give me some guidance on this logic?

Perhaps this is best explained with an example.
(see src/test/regress/sql/partition_merge.sql).

(a) Create permanent table "t":

SET search_path =3D partitions_merge_schema, pg_temp, public;
CREATE TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE tp_0_1 PARTITION OF t FOR VALUES FROM (0) TO (1);
CREATE TABLE tp_1_2 PARTITION OF t FOR VALUES FROM (1) TO (2);

(b) Attempt to merge persistent partitions tp_0_1, tp_1_2 into
temporary partition tp_0_2:

SET search_path =3D pg_temp, partitions_merge_schema, public;
-- Can't merge persistent partitions into a temporary partition
ALTER TABLE t MERGE PARTITIONS (tp_0_1, tp_1_2) INTO tp_0_2;

(c) "ALTER TABLE ... MERGE PARTITIONS ..." will return an error:

ERROR:  cannot create a temporary relation as partition of permanent=20
relation "t"

--=20
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com