On 2018/11/02 10:51, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 01:04:43PM +0900, Michael Paquier wrote:
>> On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote:
>>> Rajkumar pointed out off-list that the patch still remains to be applied.
>>> Considering that there is a planned point release on Nov 8, maybe we
>>> should do something about this?
>>
>> Yes doing something about that very soon would be a good idea. Tom,
>> are you planning to look at it or should I jump in?
>
> And so I am looking at v3 now...
Thanks for looking.
> Adding a test case in temp.sql would be nice.
Good idea, done.
When writing the test, I noticed something to be pointed out. As of
1c7c317cd9d, partitions of a temporary partition table themselves must be
temporary, but the ON COMMIT action has to be specified for each table
separately. Maybe, there is nothing to be concerned about here, because
there's nowhere to record what's specified for the parent to use it on the
children. So, children's CREATE TABLE commands must specify the ON COMMIT
action for themselves.
> Would it make sense to support TRUNCATE on a materialized as well in the
> future? It seems to me that it is dangerous to assume that only
> relations make use of heap_truncate_one_rel() anyway as modules or
> external code could perfectly call it. And the thing is documented
> to work on a relation, including materialized views, not just an
> ordinary table which is what RELKIND_RELATION only mentions. On the
> contrary we know that heap_truncate() works only on temporary
> relations. It is documented to do so and does so.
>
> So it seems to me that Tom correctly mentioned to add the check in
> heap_truncate, not heap_truncate_one_rel(), so v3 looks incorrect to
> me.
Okay, I agree that adding the preventive check in heap_truncate is a good
idea.
Updated patch attached.
Thanks,
Amit