Re: Partitioning with temp tables is broken - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Partitioning with temp tables is broken
Date
Msg-id 20180620015439.GA20245@paquier.xyz
Whole thread Raw
In response to Re: Partitioning with temp tables is broken  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Partitioning with temp tables is broken
List pgsql-hackers
On Tue, Jun 19, 2018 at 04:26:56PM +0530, Ashutosh Bapat wrote:
> On Tue, Jun 19, 2018 at 4:22 PM, Michael Paquier <michael@paquier.xyz> wrote:
>> I was under the impression that this was implied in the precious
>> phrasing but you guys visibly don't match with my impression.  So I
>> would suggest this paragraph at the end:
>> "Mixing temporary and permanent relations in the same partition tree is
>> not allowed.  Hence, if the partitioned table is permanent, so must be
>> its partitions at all levels and likewise if the partitioned table is
>
> You don't need to mention "at all levels", its implied recursively.

Okay, done on master and REL_10_STABLE.  I have adapted the tests and
the code on v10 where default partitions do not apply.  I have also
removed the test case for partition pruning in REL_10_STABLE as those
have been mainly added by 8d4e70a6, master of course keeps it.

I have included Ashutosh's last suggestions and finished with the
following phrasing:
"Mixing temporary and permanent relations in the same partition tree is
not allowed.  Hence, if the partitioned table is permanent, so must be
its partitions and likewise if the partitioned table is temporary.  When
using temporary relations, all members of the partition tree have to be
from the same session."

I am not sure why this set of emails does not actually appear on
UI interface for archives of pgsql-hackers...  All hackers are receiving
that, right?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Next
From: Andrew Dunstan
Date:
Subject: Re: Fast default stuff versus pg_upgrade