MIME-Version: 1.0
References: <c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582@postgrespro.ru>
 <3a4b9c1c-3edf-4e29-9629-b4113aefb0f3@postgrespro.ru> <CAPpHfduNYkMVuUSxZjD6u4tZG6aKdhgQcmhr-K9OQfeg56MNww@mail.gmail.com>
 <c3730d78-6081-4c41-9715-d1d192734576@postgrespro.ru> <CAPpHfdtj7YsPaASoVPN+N3H4_Ct+kQw8QY1d_9u7FPnbghkicw@mail.gmail.com>
 <CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw@mail.gmail.com>
 <28ed1ee0-749d-9838-955e-abff42fc44be@gmail.com> <ce654fca-74cf-44fb-a7e6-d35e3718179c@postgrespro.ru>
 <CAPpHfdtTgSdbzfcEz_mgVxh8VSDP=VfQ6r4T1n9SMT_impbDiA@mail.gmail.com>
 <b56918c2-b099-9875-aa4e-8fd405cdb6ab@gmail.com> <dbc8b96c-3cf0-d1ee-860d-0e491da20485@gmail.com>
 <86bfd241-a58c-479a-9a72-2c67a02becf8@postgrespro.ru> <CAMbWs49c_7dT_oiP729b-JPRiDtTuDca3exN_cOZZwjGG-0bMA@mail.gmail.com>
 <b907ce77-c054-4009-a871-4d55cb3f73f9@postgrespro.ru> <fdaa003e-919c-cbc9-4f0c-e4546e96bd65@gmail.com>
 <edfbd846-dcc1-42d1-ac26-715691b687d3@postgrespro.ru> <0f655bcd-6487-4179-f9cf-c248efbad510@gmail.com>
In-Reply-To: <0f655bcd-6487-4179-f9cf-c248efbad510@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Fri, 12 Apr 2024 04:53:43 +0300
Message-ID: <CAPpHfdv1ZkY9cPOqsLvDY9AA-fCYKHM4P07+-Mu+xq5o=daS6w@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfdv1ZkY9cPOqsLvDY9AA-fCYKHM4P07%2B-Mu%2Bxq5o%3DdaS6w%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 11, 2024 at 8:00=E2=80=AFPM Alexander Lakhin <exclusion@gmail.c=
om> wrote:
> 11.04.2024 16:27, Dmitry Koval wrote:
> >
> > Added correction (and test), see v3-0001-Fix-for-SPLIT-MERGE-partitions=
-of-temporary-table.patch.
> >
>
> Thank you for the correction, but may be an attempt to merge into implici=
t
> pg_temp should fail just like CREATE TABLE ... PARTITION OF ... does?
>
> Please look also at another anomaly with schemas:
> CREATE SCHEMA s1;
> CREATE TABLE t (i int) PARTITION BY RANGE (i);
> CREATE TABLE tp_0_2 PARTITION OF t
>    FOR VALUES FROM (0) TO (2);
> ALTER TABLE t SPLIT PARTITION tp_0_2 INTO
>    (PARTITION s1.tp0 FOR VALUES FROM (0) TO (1), PARTITION s1.tp1 FOR VAL=
UES FROM (1) TO (2));
> results in:
> \d+ s1.*
> Did not find any relation named "s1.*"
> \d+ tp*
>                                            Table "public.tp0"
> ...
>                                             Table "public.tp1"

+1
I think we shouldn't unconditionally copy schema name and
relpersistence from the parent table.  Instead we should throw the
error on a mismatch like CREATE TABLE ... PARTITION OF ... does.  I'm
working on revising this fix.

------
Regards,
Alexander Korotkov