On Mon, Jun 22, 2026 at 1:44 PM Pavel Borisov <[email protected]> wrote: > On Sun, 21 Jun 2026 at 16:11, Alexander Korotkov <[email protected]> wrote: > > > > On Thu, Jun 18, 2026 at 6:49 PM Justin Pryzby <[email protected]> wrote: > > > On Thu, Jun 18, 2026 at 10:31:11AM +0300, Alexander Korotkov wrote: > > > > Pushed with your suggestions accepted. > > > > > > Thanks. When I went back to test this, I merged ~25 partitions that > > > were all on the same tablespace, but the merged table was created on the > > > default tablespace. > > > > > > I tried again with default_tablespace set, but it was ignored. I think > > > that's wrong. It's good to follow the tablespace of the parent table, > > > but if it has no tablespace set, default_tablespace should be obeyed. > > > See surrounding logic in DefineRelation. > > > > > > I see the docs say this: > > > + <command>ALTER TABLE MERGE PARTITION</command> uses the > > > partitioned > > > + table itself as the template to construct the new partition. > > > + The new partition will inherit the same table access method, > > > persistence > > > + type, and tablespace as the partitioned table. > > > > Correct, please see the attached patch, it makes > > createPartitionTable() deal with tablespaces the same was as > > DefineRelation() does. > > Thank you for working on this feature! > I've looked into the last v1 patch. > > Does it also worth inheriting DefineRelation()'s check and error for > the case if (tablespaceId == GLOBALTABLESPACE_OID)? > A brief look for default_tablespace GUC doesn't reveal a way why it > could not be set to global tablespace in a session.
Thank you for catching this. I've added this check and corresponding tests. ------ Regards, Alexander Korotkov Supabase
v2-0001-Take-into-account-default_tablespace-during-MERGE.patch
Description: Binary data
